Hi Patrick,

In principle I agree that that would be the cleanest solution. I did
> consider this but ruled it out due to practical issues. Maybe I should have
> mentioned that in the first email, but was afraid that it would cause
> distraction from the main topics.
> I think the unit conversion are best done inside the iy-methods for
> several reasons:
> * The conversion requires access to a number of variables and that is most
> easily guaranteed inside iy-methods. Even if we would make all those
> quantities ppvar-ones, we still have the next issue.

Why is it a problem to output more variables?  They are already generated
so instead of throwing them away at exit of iy you throw them away in y or
use them for the conversion.  This will allow outputting things like the
transmission without having to repeat calculations, and you can throw away
the entire iy_aux variable because there is another way to set those things.

It also cleans up the documentation significantly, or it would if these
features and behavior were documented in the first place.  (I am to blame
for not updating the documentation for much of this, but it is difficult to
write down the theory when there are so many exceptions inside all the

> * Outside of iy-methods the Jacobian values are on individual grids, and
> we then need to interpolate other quantities to make the conversion, that
> is negative for numerical accuracy. In addition, the resolution along the
> path should in general be much better than the one implied by the retrieval
> grids. For this reason, I think it is best to do the conversion for
> Jacobian values along the ppath (i.e. convert diy_dpath, and not diy_dx)

That is my point.  Just have the iy-functions output the path variables
that are computed and you have the conversion in yCalc to fit with the
Rodger's theme.  This way you do not have to introduce a lot of repeated
code inside the iy-functions.  There are also cases when it would be nice
to be able to study, e.g., diy_dpath, but it is not even an ARTS variable
at this point.  It is instead computed and thrown away.

> * The last point is especially important for quantities that create
> dependencies between Jacobians. For example, if temperature and water are
> retrieved, the temperature Jacobian depends on if vmr or RH is used for
> humdity. (I think temperature + species ND retrievals cause an error now,
> as this type of dependence not yet is handled.)

Now you are losing me.  RH and temperature are of course connected but why
does this make it necessary to compute this at a level where the connection
between RH and temperature have no impact?  If you have a function at some
level that computes this connection, surely this is where the partial
derivatives should be fixed?  You are creating another scenario where it
will be difficult to keep track of what is going on.  Code, theory, and
their documentation will be difficult to keep straight.

I would suggest that you have a "jacobian_theoretical_connections" agenda
called after the iy-agenda that introduces all of the connections that you
wish to add.  (Call it something else if you want to.)  Such an agenda
could consider things like HSE, RH, and the likes.

> To convert wind Jacobians to m/s outside of iy, does that not be in
> contradiction to your own overall preference? Anyhow, if that would make
> the coding easier, I would not mind to put that among other unit
> conversions.

I suggest moving the frequency conversions inside propmat_clearsky_agenda
because it is physics related to the absorption profile so it should be
dealt with inside not external.  My entire suggestion is that we should try
to keep the physics we do more clearly where it is important and not add

> I can not judge right now if HSE can be incorporated as post-processing.
> Seems that you started to work on HSE, so you can judge this better at this
> point.

HSE is pure post-processing in iy so it should be OK to move it anywhere.
It will take some time before I am done because my ARTS work at the moment
is focused on the rotation NLTE stuff and the line-mixing module.

> I am on a workshop this week, so no time for digging into details or
> starting any ARTS coding right now. First step is to agree on the overall
> plan. My suggestion is to make unit conversions towards the end of
> iy-methods (not outside for reasons discussed above). OK?

I understand.  The plan is OK but I think if you are planning to undertake
this task you will need to move around a lot of things.  It is the perfect
opportunity to try and separate the physics we compute from the physics we

arts_dev.mi mailing list

Reply via email to