<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Quicker processing speeds?</TITLE>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2900.2963" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2>Dear Rémi and TRNSYS users,</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>We recently did some experimenting with a dual-core 
processor. Our aim was actually to find out if the hard disk writing of a 
computer could be saturated by large TRNSYS outputs and thus become a 
bottle-neck in simulations with big output files (and it seems like not easily 
with standard modern computers).</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>But...</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>To benefit from a dual core processor a program 
must be multi-tasking, i.e. it must create multiple threads for the operating 
system (OS) which the OS can then run in parallel. TRNSYS does not create 
multiple threads, so if you are running only one simulation on a dual core 
processor, it will run just as fast as if you would run it on a single core. 
</FONT><FONT face=Arial size=2>However, you can run two TRNSYS simulations 
simultaneously, and the OS will then run each simulation on its own 
core. This means that you can run e.g. two parametric studies (or 
divide one into two) at the same time and thus halve the needed time.  
</FONT><FONT face=Arial size=2>BUT TAKE CARE: you must run two decks from 
separate directories and see that also the output files end up in different 
directories!!! (or change the names) Otherwise the simulations will write 
to same files, the output data of the first started will be replaced by the 
later started. </FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2>I have no knowledge of how much you can benefit of 
dual core processors when calling other programs from TRNSYS or with plugins. 
But based on what is stated above, I'd say that you will benefit only, if the 
other programs can do something useful <U>while</U> TRNSYS is solving. If TRNSYS 
solver pauses for feedback from the other program and vice versa for each 
iteration or time-step, you will probably have no notable perfomance boost. But, 
for example, if the other program does data processing or writing to the 
hard disk each time step <U>after</U> it has given feedback to TRNSYS then you 
might benefit, as this will be done by the other core and TRNSYS can 
continue a bit earlier. You have to try and see... </FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Also, I don't know what happens with communication 
between TRNSYS and the other programs if there are several instances running... 
I have only tried with TRNSYS without external connections.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>
<DIV><FONT face=Arial size=2>I'd also be very interested to hear if other people 
have more experience on this.</FONT></DIV></FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>What comes to RAM, you should check how much you 
are using with current simulations. You can do that with the windows performance 
monitor by checking how much RAM is used and how much it changes when you start 
a simulation. Additional RAM will only help if the OS is writing to the paging 
file (virtual memory on hard disk) <U>while</U> you are running the simulation. 
1GB for the computer should be more than enough, but it depends of course on 
what other programs and system processes are running simultaneously... 
TRNSYS does not eat memory as e.g. FEM/CFD does.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>What comes to processor speeds, the sim time should 
be somewhat directly proportional to processor speed, so faster is better. That 
is, if there are no other bottle-necks on the motherboard (bus 
speeds, cache etc.). Usually in good quality commercial computers (or built by 
experts) there should be no problems with processor not being optimized with 
motherboard. (but changing a processor to your existing motherboard is another 
thing...)</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Hope that helps at least as a starting 
point...</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Cheers</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial 
size=2>-----------------------------------------------------------------------------<BR>Janne 
Paavilainen <BR>MSc, PhD student<BR>Researcher in Energy and Environmental 
engineering<BR>-----------------------------------------------------------------------------<BR>Solar 
Energy Research Center SERC<BR>Dalarna University College<BR>SE-781 88 
Borlänge<BR>Sweden<BR>-----------------------------------------------------------------------------<BR>tel 
+46 (0)23 778728<BR>fax +46 (0)23 778701<BR>e-mail: <A 
href="mailto:jip@du.se">jip@du.se</A><BR>-----------------------------------------------------------------------------<BR><A 
href="http://www.du.se">www.du.se</A><BR><A 
href="http://www.serc.se">www.serc.se</A><BR><A 
href="http://www.eses.org">www.eses.org</A><BR><A 
href="http://www.uni-kassel.de/fb15/ite/solar/solnet/">www.uni-kassel.de/fb15/ite/solar/solnet/</A><BR>-----------------------------------------------------------------------------<BR></FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<BLOCKQUOTE 
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV 
  style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B> 
  <A title=remi.charron@nrcan-rncan.gc.ca 
  href="mailto:remi.charron@nrcan-rncan.gc.ca">Charron, Rémi</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>To:</B> <A title=trnsys-users@engr.wisc.edu 
  href="mailto:trnsys-users@engr.wisc.edu">trnsys-users@engr.wisc.edu</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>Sent:</B> Friday, November 10, 2006 6:43 
  PM</DIV>
  <DIV style="FONT: 10pt arial"><B>Subject:</B> [TRNSYS-users] Quicker 
  processing speeds?</DIV>
  <DIV><BR></DIV><!-- Converted from text/rtf format --><BR>
  <P><FONT face=Arial size=2>Hello,</FONT> <BR><FONT face=Arial size=2>I am 
  currently running TRNSYS with using a computer with a 3.2 GHz prcoessor with 
  512 MB of RAM.  It takes approximately 100 seconds to run a 
  simulation.  This is a reasonable amount of time, except that I am 
  running TRNSYS with an optimisation program and am requiring to perform 
  thousands of TRNSYS simulations per run.  I am thinking of getting a 
  quicker computer or workstation to help speed TRNSYS up.  Has anyone had 
  experience running TRNSYS using duel core processors or other high performance 
  computers or workstations?  If so, what have been your experiences?  
  Can the computation time be significantly reduced with the use of a more 
  powerful computer?</FONT></P>
  <P><FONT face=Arial size=2>Thanks,</FONT> </P>
  <P><FONT face=Arial size=2>Rémi Charron</FONT> <BR><FONT face=Arial 
  size=2>Research Officer</FONT> <BR><FONT face=Arial size=2>Photovoltaic and 
  Hybrid System Program</FONT> <BR><FONT face=Arial size=2>CANMET Energy 
  Technology Centre</FONT> <BR><FONT face=Arial size=2>1615 Lionel-Boulet Blvd, 
  P.O. Box 4800, J3X 1S6</FONT> <BR><FONT face=Arial size=2>Varennes, 
  Quebec</FONT> <BR><FONT face=Arial size=2>Tel: (450) 652-7948, Fax: (450) 
  652-5177</FONT> <BR><A href="http://cetc-varennes.nrcan.gc.ca"><U><FONT 
  face=Arial color=#0000ff 
  size=2>http://cetc-varennes.nrcan.gc.ca</FONT></U></A> </P>
  <P>
  <HR>

  <P></P>_______________________________________________<BR>TRNSYS-users mailing 
  list<BR>TRNSYS-users@engr.wisc.edu<BR>https://www.cae.wisc.edu/mailman/listinfo/trnsys-users<BR></BLOCKQUOTE></BODY></HTML>