About the current setup, it is indeed a heritage from the past. I just
copied your setup. You had all unit conversion local.
Yes, "mea culpa".
I like the idea to allow more units but I think this should be handled
at a later stage than the iy-functions.
I have argued before that it would be a very good idea to ensure that
all output from iy-functions are purely dependent on the physics of the
underlying calls --- that is on the inputs to the iy-functions. All
additional conversions should happen in y-functions that have been
designed to fit with Rodgers-like computations.
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
* 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.
* 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)
* 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.)
This would still force the conversion of wind-field to m/s instead of Hz
after propmat^, but it would remove VMR, HSE, iy-conversion and
jacobian-transformation from this code placing it at a later stage. (If
you want HSE, then this and all that it depends on should be input as a
variable so that the derivatives can be computed based on 'actual'
theory instead of understood theory. You know the problem the latter
has caused because of the switch in how layers work in iy***2 functions.)
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
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
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?
arts_dev.mi mailing list