Welcome to the TRNSYS Users Forum.
The forum is a place where people can interact and have discussions about different topics involving the use of the TRNSYS software package. Here you can post topics for discussion or questions on using TRNSYS and get advice from other users or TRNSYS experts. This forum is not intended for detailed technical support. Users should contact their distributor’s hotline for such assistance.
Some tips for success on using the forum:
- Follow the Forum Rules posted in Forum Administration.
- There are categories for different types of topics and questions. Post your topic or question into the proper category.
- Before posting a topic or question search the existing topics (and the TRNSYS Users listserv archive or Post archive) to see if a similar topic or question has already been answered.
- Use a descriptive topic name. Don’t use attention getting subjects, they don’t get attention and only annoy people.
- State the version of TRNSYS and which add-ons your are using.
- Include enough specific details for your topic of question to be answered. Just posting “Why am I getting an error?” without describing the specific error and what you are trying to do when you get the error will not receive a response that fixes your issue.
- Remember when people help you, they are doing you a favor. Be patient, help people out by posting good descriptions of what you need help with, and be polite even if a response does not solve your issue.
- Moderators may edit your post for clarity or move your topic to a more appropriate category.
Hi,
I am wondering if it would be possible to run TRNSYS on Linux servers? I have a district model which should run over a year. Although I have used coarse mesh in Type 997, it took me around 5 days now and only 20% of the model has finished. I have 60 parameters in my Printegrator, 72 parameters in my printer. I also have 50 parameters in Type 65a. My timestep is also 1 minute. The PC that I am using has Core I7-4790K, 32GB DDR3 RAM and NVidia GeForce GTX980 graphical processor.
I would appreciate it if you could let me know of any ways to improve the processing time.
Thanks
Shams
The answer to your first question is: unfortunately no, Trnsys18 and earlier versions of TRNSYS require a Windows environment to run. This might be an option available in Trnsys19, but that's as-yet undetermined.
Some suggestions for improving your run time:
*You can verify the run time of each Type in your simulation by setting Debug Mode to True (Settings or gear icon -> Advanced Settings), then opening the .lst file when the simulation ends and scrolling to the bottom. I am pretty certain the time in Type 997 will far outpace the time in any of the printegrator, printer, or plotter components, but with Debug on you can verify that for sure. It will take a little longer to run with Debug on, so I recommend turning it off once you have some data to work with. (The Simulation Studio setting 'debug mode' is different from the compiler 'debug' mode; see next suggestion below).
*I believe from past correspondence you may have re-compiled the .dll for TRNSYS and/or Type997. If/when you re-compiled, did you re-compile in release mode, or debug mode? Release mode will run *much* faster than debug mode. You can verify which mode you're running by checking the second 'Notice' in the 'Results, warnings, and errors' window after the simulation runs (the notice is also printed near the top of the .lst file). Also, if you're using Visual Studio, you can turn on optimizations in Release mode with the following compiler settings: Configuration Properties > Fortran > Optimization > maximize speed; Configuration Properties > Fortran > Floating Point > Floating point model > precise (/fp:precise); Configuration Properties > Fortran > runtime > Runtime error checking > None (check:none); Configuration Properties >Fortran > Floating Point > Reliable Floating Point Exceptions Model: Enable (/fp:except). Compiling in release mode with optimizations on can improve run time for a heavily-noded simulation dramatically, especially with a multi-core processor (see below).
*Do you have a multi-core processor? With optimizations on, a multi-core processor can take advantage of parallel processing to improve the speed with which it stores and retrieves information from the arrays within the Type. More cores is better, though of course the law of diminishing returns applies.
*Anything you can do to reduce the # of nodes in Type997 and/or the timestep could make a huge improvement. I know you said you were using a coarse mesh for Type997; have you verified how many X, Y, and Z nodes you are using in your implementation? How many pipes are you running, how many nodes per pipe length, how many layers, what's your minimum node size and multiplier, how far to the farfield, etc. If you have on/off controllers in your project that cycle frequently (thermostats for heat pumps, etc), I would run a 5-minute timestep if at all possible. If you're not using on/off controllers, or your controls cycle less frequently, you may run a 10-minute or even 15-minute timestep.
*You can turn the online plotter(s) off by changing Parameter 9 in each plotter from 0 to -1. (I'm not sure how you have 52 parameters in Type65 when the max # variables is 10 per axis?) That won't make a huge difference, but even a few percent improvement on a long simulation can be worthwhile.
It's not uncommon for runs with Type997 to take awhile, though 5 days to run 20% of a 1-year model does seem longer than I would expect. Hope one of the above suggestions helps.
