Add start and end time for source addition, update documentation

[timofeymukha]

• Adds start_time and end_time json parameters for source terms, so as to limit the execution of the source term in time whe necessary.
• Does not affect the user source terms, because they don't get init from the json and things become difficult. Warnings are issued to the log if the keywords are present. The idea is that you can anyway always put any ifs you need right in your user source code.
• To accommodate this, the interface of the source_term_t is changed to have the new parameters (descendents have to parse the start_time and endtime from the json now before sending them to the base type constructor). The deferred routine is now called `compute, whereascompute` wraps that with the check on the current time and the user-selected time start and end time. This is exactly the same structure as in the simcomps.
• User source term types already used compute_ for other purposes, that routine is now renamed to compute_vector_
• I init end_time to huge(0.0_rp) by default. Is this fine to use, @njansson?
• Outdated documentation regarding the source terms is removed and new one added.

[timfelle]

So, how about changing the names to compute for the actual execution (as it is at the moment) and then use "update" for the deferred operators? That might be clearer than having all the "_" methods.

[njansson]

looks good! huge(0.0_rp) is fine

[timofeymukha]

So, how about changing the names to compute for the actual execution (as it is at the moment) and then use "update" for the deferred operators? That might be clearer than having all the "_" methods.

The is our convention to point out that something is private, a bit similar to Python. But in this case I think I will also make `compute` private as well to make sure it cannot be called from the outside. My concern with "update" is that it will be somewhat unclear which one is the wrapper and which "the real thing".

[timofeymukha]

So, how about changing the names to compute for the actual execution (as it is at the moment) and then use "update" for the deferred operators? That might be clearer than having all the "_" methods.

The is our convention to point out that something is private, a bit similar to Python. But in this case I think I will also make `compute` private as well to make sure it cannot be called from the outside. My concern with "update" is that it will be somewhat unclear which one is the wrapper and which "the real thing".

Hmm, it seems deferred private procedures have some limitations, if one is to believe this. https://stackoverflow.com/questions/48023393/how-to-design-a-private-overridable-procedure-in-an-abstract-derived-type It says all the types have to be in the same module. However, prior to reading this, I implemented locally and compiled with compute_ set to private both in the base type and the descendents. Perhaps, compiler dependent? @njansson do you have some wisdom on this?

[timfelle]

The is our convention to point out that something is private, a bit similar to Python. But in this case I think I will also make `compute` private as well to make sure it cannot be called from the outside. My concern with "update" is that it will be somewhat unclear which one is the wrapper and which "the real thing".

Sure thing, its all a matter of taste. I am just not sure compute is the word i would use for outward facing one. I would say it is "applying" the source term to the bigger system and the internal one "computes" the values of the source term.

[timofeymukha]

The is our convention to point out that something is private, a bit similar to Python. But in this case I think I will also make `compute` private as well to make sure it cannot be called from the outside. My concern with "update" is that it will be somewhat unclear which one is the wrapper and which "the real thing".

Sure thing, its all a matter of taste. I am just not sure compute is the word i would use for outward facing one. I would say it is "applying" the source term to the bigger system and the internal one "computes" the values of the source term.

The reason for the compute for the outward-facing one is a bit historical. At some point we had a lot of different names for this kind of routines, like "update", "compute", "apply", etc. And then at some point we said, let's call them all compute to homogenize things. So, if you open fluid_pnpn_step, it is sprinkled with stuff that executes %compute on itself:-). It kind of became the standard name for the "update your stuff once per time-step" routine. Although, admittedly, some update and apply are still present as well since no one bothered to take the time to change it.

[timfelle]

The is our convention to point out that something is private, a bit similar to Python. But in this case I think I will also make `compute` private as well to make sure it cannot be called from the outside. My concern with "update" is that it will be somewhat unclear which one is the wrapper and which "the real thing".

Sure thing, its all a matter of taste. I am just not sure compute is the word i would use for outward facing one. I would say it is "applying" the source term to the bigger system and the internal one "computes" the values of the source term.

The reason for the compute for the outward-facing one is a bit historical. At some point we had a lot of different names for this kind of routines, like "update", "compute", "apply", etc. And then at some point we said, let's call them all compute to homogenize things. So, if you open fluid_pnpn_step, it is sprinkled with stuff that executes %compute on itself:-). It kind of became the standard name for the "update your stuff once per time-step" routine. Although, admittedly, some update and apply are still present as well since no one bothered to take the time to change it.

Yea it always ends up that way when the system becomes big enough. Good names for things are hard, I always rename things 10-15 times as i develop them... Often it is also just a question of having good enough documentation of what does what and then it will be fine.