Dear Patrick, I think this is a move in the right direction. Good to have a clear strategy, otherwise the complexity will quickly get out of control.
Cheers, Stefan > On 3. Dec 2017, at 13:52, Patrick Eriksson <patrick.eriks...@chalmers.se> > wrote: > > Hi Simon, Richard and all, > > I started to think about how to allow a log10 retrieval "unit" for scattering > quantities. As often happens, this ended with that I want to make a general > cleaning and reorganisation. > > My idea is to move towards a more clear distinction between unit and > transformations. In addition, we have to deal with two types of > transformations, linear and non-linear. I think these three shall be applied > in the order: unit, non-linear and linear. > > Comments: > > unit: This would now just be pure unit changes, such as "nd" (number > density). Later I would also like to allow relative and specific humidity for > H2O. We could also allow "C" for temperature ... > > (Units changes will be specific for each retrieval quantity, while > transformations shoul be implemented in a general manner.) > > Non-lin transformations: I would like to remove the "logrel" option (now an > unit option). And instead generally introduce "log" and log10" (without > ruling out to add more transformations, such as tanh+1?) > > Linear transformations: As already introduced by Simon. > > The unit part will be handled by the iy-methods. For the transformations I > suggest to extend the scope of present jacobianTransform (as well as merging > it with jacobianAdjustAfterIteration, that handles a rescaling for "rel" > necessary for iterative OEM). > > > All: Comments? Something that I have missed? > > > Richard: The handling of units seems a bit messy to me. The function > dxdvmrscf is applied in get_ppath_pmat_and_tmat, but only if from_propmat. > dxdvmrscf is also applied in adapt_stepwise_partial_derivatives. This > confuses me, but could be an heritage of my old code. > Would it not be simpler if the core code just operates with ARTS default > unit, i.e. vmr for abs species? And then the conversion is done only on the > final jacobian values (along the ppath). This should be a general function, > called towards the end of all iy-methods providing jacobians. > As far as I can see that should work, and should give cleaner code. Agree? Or > have I missed something? > > 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ arts_dev.mi mailing list arts_dev.mi@lists.uni-hamburg.de https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi
