[TRNSYS-users] DERIVATIVES/setNumericalDerivative/getNumericalSolution vs. roll your own

[thornton at tess-inc.com]

On 2023-03-31 05:29, Damian Birchler via TRNSYS-users wrote:

Damian - awesome post and great questions!  Let me start where you ended 
and work backwards.

> Are we developing are in-house types in a "wrong" way?

I would argue that every model and every simulation is "wrong"...LOL  We 
make simplifying assumptions and use solution techniques that do not 
perfectly represent the systems that we are modeling.  Even something as 
accepted as a time step in TRNSYS is an approximation made to allow for 
a solution in a finite amount of time.  The answer comes down to "How 
Wrong" is acceptable for your analysis.

> Is DERIVATIVES & friends just
> 
>  	* A user-friendly utility that helps a type developer may use to
> solve their ODEs

My opinion: Yes.

> 	* The preferred way of solving ODEs for overall convergence reasons
> (by "overall" I mean system-wide; between all units)

Well it's not my preference and I've written thousands of TRNSYS models 
and hundreds that solve differential equations.  I have found that 
solving them internally can greatly speed up a simulation as opposed to 
solving them externally.  Remember that every time a TRNSYS Type gets 
called it updates it's outputs - which then requires the call (or at 
least a check) of every component that uses the outputs of that model - 
and then the models that use the outputs of the model that use the 
outputs of your model.  I also prefer to solve them internally because I 
can build in some restraints that bound the physical problem.  For 
example the outlet temperature of a cooling tower can't be any colder 
than the ambient conditions that the tower is communicating with.  I 
also will routinely use other numerical techniques within my models 
(Newtons method for example) and having my black box model be able to 
solve its own problem internally can be very helpful.  And I believe 
that there are times when solving the Diff Eq's internally may be the 
only practical way of doing it.  Our sub-surface ground models literally 
solve tens of thousands of differential equations each timestep and some 
use advanced matrix methods.  Not sure if I could even do that in TRNSYS 
using the external solver.

> 	* …for overall correctness reasons?

I don't have a PhD in mathematics so I'm not sure I'm qualified to 
answer that on a purely theoretical basis.  But after 30+ years of using 
TRNSYS, calibrating our models and simulations to detailed measured data 
on everything from buildings to tanks to solar collectors to PCM storage 
devices, I can safely say that my real-world experience is that solving 
them internally is an extremely effective and accurate way of doing it.  
Is it "Right"?  Don't know.  But it's "Right Enough" for the accuracy 
that I'm looking for and at the end of the day that's what is important. 
  Everything we model requires assumptions and I feel that this one is 
low enough on the spectrum that I'm comfortable with it.  More 
comfortable with it then the assumption of constant fluid properties!  
LOL

Jeff
------------------------------------------------------------------------------------
> Many of our in-house types as well as the few TESS types that I've
> looked at solve their ODEs internally, using a wide variety of methods
> from numerical to evaluating the explicit solution directly.
> 
> I'm very unclear about the (dis-)advantages of doing that vs. using
> the TRNSYS built-in functionality of
> DERIVATIVES/setNumericalDerivative/getNumericalSolution. Is
> DERIVATIVES & friends just
> 
>  	* A user-friendly utility that helps a type developer may use to
> solve their ODEs
> 	* The preferred way of solving ODEs for overall convergence reasons
> (by "overall" I mean system-wide; between all units)
> 	* …for overall correctness reasons?
> 
> My question is "informed" by Wikipedia's page on DAEs:
> https://en.wikipedia.org/wiki/Differential-algebraic_system_of_equations
> [1].
> 
> After skimming through it, I was wondering what it means if (for the
> purpose of this discussion) the ODEs of all units within a simulation
> are hidden in the blackbox of their corresponding unit, then the
> system to TRNSYS' eyes is completely "algebraic"…
> 
> Are we developing are in-house types in a "wrong" way?


-- 
----
Jeff Thornton
President
Thermal Energy System Specialists (TESS)
3 N. Pinckney Street - Suite 202
Madison WI 53703
(608) 274-2577
www.tess-inc.com