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 functions.) > * 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 exceptions. > 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 presume. //Richard
_______________________________________________ arts_dev.mi mailing list arts_dev.mi@lists.uni-hamburg.de https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi
