[TRNSYS-users] Stuck simulation
David Bradley
bradley at tess-inc.com
Thu Sep 3 07:20:11 PDT 2009
Vincent,
Usually when you get into that "disassembly window" it means that the
actual crash has occurred inside the TRNExe and not inside the Fortran
code. Its not any easy thing to figure out. One thing you might try, if
you haven't already, is to turn on the debugging switch in the Studio
control cards. Among other things, that will activate two checks at the
end of each time step. One check will make sure that none of the
components wrote outside of the OUT() array space that is allocated to
them. The other check will make sure that none of the outputs of any of
the components get set to the "NaN" (not a number) condition.
Kind regards,
David
Vincent Dolisy wrote:
> Dear David,
>
> I've got a Fortran compiler and I can run the simulation from this.
> (Compaq Visual Fortran)
>
> I have set a breakpoint in the trnsys.for file at the end of the timestep:
>
> C AT THIS POINT THE SIMULATION IS FINISHED AT THE CURRENT TIMESTEP
> RETURN
>
> In fact I add this breakpoint at the timestep just before the simulation
> begins to be stuck. Then I run it line by line and hope to find an
> infinite loop or something like that. When I run it line by line the
> source code window switches to the "Disassembly window" so that I cannot
> see any source code lines anymore. In the "Disassembly window" each line
> is scanned one by one until the cursor stops at the line:
>
> 0046F993 call eax
>
> Do you know how I can find the source code line (or file) corresponding to
> a line in the "Disassembly window"?
>
> The way I debug is maybe not good. Do you know any good strategy to debug
> this kind of problem ?
>
> Thanks a lot.
>
> Kind regards,
> Vincent
>
>
>
>
>> Vincent,
>>
>>
>>> *TRACE* UNIT 51 TYPE 56 AT TIME 2.6764166666666665E+03 ITERATION
>>> 2 CALL 13105 POST-CONVERGENCE CALL. (can you tell me what it
>>> means?)
>>>
>>>
>> once TRNSYS converges on a solution at a given time step, the kernel
>> calls all types once more so that they can do anything that they might
>> need to do (update summaries, print reports for that time step, make
>> control decisions that are not supposed to be iterative, etc.)
>>
>>> The simulation time step is 1 minute and if I use 5 minutes it does not
>>> hang up at the same hour.
>>>
>>> Moreover I have already encountered the problem during the night, that
>>> is
>>> to say when the system is turned off (heating coils, cooling coils,
>>> humidifiers, PID's are switched off).
>>>
>>>
>> all of those suggest that there is something that gets stuck in an
>> infinite loop. The only way to really track it down is to run it from
>> the Fortran compiler I am afraid,
>> Kind regards,
>> David
>>
>>
>> --
>> ***********************************************************************
>> Thermal Energy System Specialists (TESS), LLC
>> David BRADLEY 22 N. Carroll Street - Suite 370
>> Partner Madison, WI 53703
>> USA
>> P: +1.608.274.2577
>> F: +1.608.278.1475
>> E-mail: bradley at tess-inc.com
>> Web Pages: http://www.tess-inc.com and http://www.trnsys.com
>>
>> ***********************************************************************
>>
>> _______________________________________________
>> TRNSYS-users mailing list
>> TRNSYS-users at cae.wisc.edu
>> https://www-old.cae.wisc.edu/mailman/listinfo/trnsys-users
>>
>>
>
>
>
--
***********************************************************************
Thermal Energy System Specialists (TESS), LLC
David BRADLEY 22 N. Carroll Street - Suite 370
Partner Madison, WI 53703
USA
P: +1.608.274.2577
F: +1.608.278.1475
E-mail: bradley at tess-inc.com
Web Pages: http://www.tess-inc.com and http://www.trnsys.com
***********************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.onebuilding.org/pipermail/trnsys-users-onebuilding.org/attachments/20090903/dfac2b7b/attachment-0005.htm>
More information about the TRNSYS-users
mailing list