Hi Richard,

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 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.

* 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 conversions.

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.

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?

Bye,

Patrick



_______________________________________________
arts_dev.mi mailing list
arts_dev.mi@lists.uni-hamburg.de
https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi

Reply via email to