MODTRAN polynomials for upper possible bounds of water vapor and lower possible bounds of AOT#689
Conversation
|
To be clear, this is what " It is imperfect in creating this artificial cap at 0.25, but perhaps is reasonable at such conditions where carrying capacity of water is so low to begin with. 
|
|
Thanks for handling the formatting, and for the clarification on the minimum water vapor bound. 0.25 is a reasonable cuttoff, the likelihood of having a column drier to that is very low. Given the last team conversation on this PR (with a positive consensus), I'm going to go ahead and merge. Now for the fun part of considering integration. My general recommendation would be that we include a filtering function of this sort into radiative_transfer_engine, which is always called but generally defaults to the full bounds. That would then give the RTE override power, and allow this utility to be RTE specific. I think the implementation's probably pretty tractable actually....but let's save that for the next PR. Thanks for the work @brentwilder ! |
MODTRAN will write to tp6 log file the theoretical maximum water column vapor and minimum AOT for a given altitude if the user provides one that is out of range for building a LUT. A lot of times this is unavoidable for scenes with wide range of ground altitude. Further, it is non-trivial to implement a rectilinear grid that is based on these theoretical max and mins that are altitude dependent.
Where this impacts ISOFIT the most is during Inversion() , which uses bounds that were declared during initialization. However, for some altitudes there may not actually be any change in the MODTRAN output, thereby creating a condition where any change in the cost surface (Jacobian) will be virtually nonexistent . This can occur especially for too coarse of water vapor resolution and large changes in altitude, where perhaps there is only 1 or 2 modtran simulations of measurable change.
A possible solution is to have a series of polynomials that we reverse-engineer out of MODTRAN to inform these bound during run time of OE. Potentially this information could be carried in the geom object, which could then reset the AOT and H2O bounds right before the main inversion. There are a lot of assumptions we have to think about though including,