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

[David BRADLEY]

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 at 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 at tess-inc.com

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