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

[Damian Birchler]

Hi Jeff

Sorry for the late reply!

Thanks for you very informative post. That was very helpful.

Cheers,
Damian

-----Original Message-----
From: thornton at tess-inc.com <thornton at tess-inc.com> 
Sent: Saturday, April 1, 2023 6:58 PM
To: TRNSYS users mailing list at OneBuilding.org <trnsys-users at lists.onebuilding.org>
Cc: Damian Birchler <damian.birchler at ost.ch>
Subject: Re: [TRNSYS-users] DERIVATIVES/setNumericalDerivative/getNumericalSolution vs. roll your own

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_equatio
> ns
> [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