|
Interesting
topic, thanks for bringing it up and all the comments. Just
to complete the Simulation Studio side: as far as plug-ins go, they are all started
in a different thread which then even starts a new process (the thread sleeps
until the process terminates). So
anything happening in a plug-in should suck at a new processor, and each new
plug in will grab a new processor as long as there is one available – at least in theory, because we’ve
never even touched such a machine here. Werner De :
trnsys-users-bounces@engr.wisc.edu [mailto:trnsys-users-bounces@engr.wisc.edu] De la part de Blair, Nate I
would just like to quickly add that I think the really critical piece for using
dual-core processors is the optimizing software. Is it sequential or can it do
a variety of runs all at the same time? I know that TRNSYS has been used with a
variety of “multi-run” tools such as Condor that send out many runs
of a software to many different computers. However, this only works if the
process is able to be parallelized (like in a monte-carlo analysis). If the
tool requires that the results of each run be analyzed before the next run is
initiated, then it must be sequential unfortunately. I’ve
also found that a dual-core is helpful with many TRNSYS runs because you can
still use the “other core” for other tasks such as email, Excel,
etc. while TRNSYS works along in the background. I’m
still waiting for a 4 Ghz machine myself. From:
trnsys-users-bounces@engr.wisc.edu [mailto:trnsys-users-bounces@engr.wisc.edu] On Behalf Of Janne Paavilainen Hi! OK, as you can see from the
replies it's quite a messy jungle with PCs nowadays. I've also been a few times
in the position of trying to justify the needs/benefits of a new work-station
for simulations (not only TRNSYS) and it's not always easy. Your interest in
reducing sim time is understandable as with your current setting you end up
easily in >24hr simulation times (thousands of 100sec sims). Trying to summarize
some guide-lines from previous mails: * If you have an older
generation CPU, then upgrading to a good PC of the current CPU generation
will probably already halve your simulation time, give or take. This you can
see e.g. from Rafs test, or comparing bench-mark results on net reviews. * If you already have a PC
with a current generation CPU, then you have to start thinking about price vs.
performance. Getting a 20-30% CPU performance boost (sim time
reduction) compared to good standard PCs might almost double the
price of your new work-station, this might be difficult to justify. * Also, looking at the
previous point: If you can divide your problem into two, buying e.g. two good
standard PCs instead one of the fastest possible, might almost halve your total
sim time instead of the 20-30% reduction for one simulation for the same price.
And after the project you have two perfectly good PCs to give to new employees,
instead of one. * The benefit of a dual-core
CPU is harder to comment on. You might be able to do with one PC the same as
with two computers as described above, but it would be better to test it before
buying. This is possible at least with TRNSYS-only, but it might be more complicated
in combination with other programs. You should be able to test this with a
single core CPU, on your current PC (the simulation will be a crawl, but
at least you should be able to see if it works). * Running two simultaneous
simulations on dual-core generates a lot of heat, take care that the cooling of
the PC is well done. If you are running simulations of several hours like this,
you might end up crashing your hard disk in no-time because of the elevated
operating temperature. This problem is not over-exaggerated!!! * With a dual core CPU you
can work normally while a TRNSYS simulation is running in the background at
full speed. This wasn't possible with single core CPUs. * RAM isn't an issue with
TRNSYS, anything above 1GB is overkill, unless you are using other software
which need more (actually, already 1GB is overkill, if only for TRNSYS+OS). * Hard disk isn't an issue
either, modern HD:s can handle about any amount of data that TRNSYS itself has
to read and can spit out. (Unless you are doing something else that's HD
intensive at the same time) A suggestion to TRNSYS
development group: It might be a good idea to
have some general guide-lines about this on the Regards Janne -----------------------------------------------------------------------------
|