[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [TRNSYS-users] Debugging own type with Microsoft Visual Studio 2010

Florian,
In the simulation control cards (where you set the simulation start time, stop time, etc.) there is a switch to turn on something called "debug mode." That switch activates two checking features in the kernel that make sure that none of the outputs of a Type were set to the "NaN" condition (not a number) and to make sure that none of the Types wrote to a spot in the global OUT() array that it did not reserve for itself. The OUT() array is an array containing a list of all the outputs of all the components in the entire simulation.
The behavior that you are describing sounds like some behaviors that we used to see before we did a good cleaning of the code in the Types. If a Type divides a number by zero, the result is set to "NaN" instead of generating an error (Windows behavior). As soon as a number gets set to "NaN" everything it touches also gets set to "NaN" and after some time, you get an error. The same is true of writing to space outside that reserved in the global OUT() array; a Type can overwrite another Type's outputs and not cause problems until much later.
It is of course not for certain that this will lead to the cause of the error you are seeing.
Also, if you are able to remove your component from the simulation and the problem continues then you should certainly send it in to tech support. You should not have to be debugging in the kernel! That is our problem not yours! 
Kind regards,
 David



On 8/7/2013 06:06, Schreiner, Florian wrote:

Dear TRNSYS Users,

I still have some problems with a new type that I have written and I don't really know how to solve them.
Unfortunately I need this type pretty urgently for my diploma thesis.
The Simulation starts and proceeds to a certain simulation-time but then it stops and the whole “TRNExe.exe” 
gets stuck without any error message and chance to find the error.
You even have to finish the “TRNExe.exe” in the Windows Task-Manager to be able to work again.
Therefore I have started to use the Microsoft Visual Studio 2010 Debugger to step through 
the code of my type and to be able to find possible errors.
Assuming that the simulation gets stuck in my own code, I set a breakpoint at a simulation-time immediately
before the error occurs and then step through the code lines. What happens is, that I can step to the end
of the code without finding any obvious error which could cause the problem.

So I go on and step out of my type with button “F11” and a “CallTypes.f90” file opens in Visual Studio 2010.
I also can step through the lines of this file and another file “Exec.f90” opens.
In this file I can step till line 411 where a DO-loop is performed. The counter of this DO-loop starts with “1”
and goes to a variable named “junits”. I guess it represents the number of units which are used in the simulation.
And finally somewhere in this loop, it get stuck.

I don't really know what this DO-loop does exactly but I guess it calls all units in sequence and
somewhere a problem occurs which crashes the whole simulation.
I still assume that my own type is corrupted and causes the problem but
I wonder why the simulation doesn't get stuck directly in the code of my type.

So I really hope that some TRNSYS-experts out there can help me and give me a hint
where the problem could be or at least what this DO-loop does exactly.

Thanks in advance!

Best regards,
Florian
_______________________________________________
TRNSYS-users mailing list
TRNSYS-users@cae.wisc.edu
https://mailman.cae.wisc.edu/listinfo/trnsys-users



--
***************************
David BRADLEY
Principal
Thermal Energy Systems Specialists, LLC
22 North Carroll Street - suite 370
Madison, WI  53703 USA

P:+1.608.274.2577
F:+1.608.278.1475
d.bradley@tess-inc.com

http://www.tess-inc.com
http://www.trnsys.com