Uh oh!
There was an error while loading. Please reload this page.
Replace Fortran Disort with C Disort - #80
Conversation
olemke
commented
Sep 23, 2019
@erikssonpatrick Is it okay with you to remove DisortCalcWithARTSSurface? Are you aware of anyone using it currently? @m-brath proposed do a new implementation at some point using the BDRF functionality available in cdisort. |
m-brath
left a comment
There was a problem hiding this comment.
FORTRAN code should be removed after final testing before merging.
erikssonpatrick
commented
Sep 23, 2019
@olemke@m-brath A good question. The surface is an issue for most of our scattering solvers! My opinion is that the scattering solvers should consider surface_rtprop_agenda and that the surface can be placed at any altitude. I assume DisortCalcWithARTSSurface was an attempt to move in this direction. Despite this, I say let's remove DisortCalcWithARTSSurface. I think it is best to start from scratch. Can you inform me about how the surface is treated right now in the cdisort version? Whatever you have done, it is OK for now. But feel free to make an issue on improving the integration of Disort and RT4 with respect to how ARTS defines the surface properties. That would be something for me if I just find the time ... |
olemke
commented
Sep 24, 2019
Currently, the surface is treated identical in C and Fortran Disort. It uses a lambertian bottom boundary with surface_scalar_reflectivity as the albedo. |
erikssonpatrick
commented
Sep 24, 2019
@olemke As I wrote, further work on the surface inside cdisort should be a new issue. But maybe this could be quickly done: If my memory is correct, cdisort can do both lambertian and specular surface. Correct? If yes, could you just add a gin to select between the two options? Then using surface_scalar_reflectivity for both options. |
olemke
commented
Sep 24, 2019
CDisort supports lambertian and different types of BRDF. I think if I turn off lambertian and set BRDF_TYPE to None, it should result in a specular surface. |
erikssonpatrick
commented
Sep 24, 2019
@olemke You wrote, "I think". If you are uncertain, can you point me to some relevant documentation and I maybe I can give a piece of advice? This would be good to know anyhow. |
olemke
commented
Sep 24, 2019
Thanks @erikssonpatrick. I'm indeed not certain, mostly due to the lack of documentation. :-( Except for the paper, everything I could find documentation-wise, is included in the source directory. This example in disotest.c seems to do non-lambertian without special BRDF, but is it really specular? Maybe you can extract some helpful information from DISORT2.doc. |
erikssonpatrick
commented
Sep 24, 2019
@olemke My conclusion is that there are two options for the surface. The simplest option is ds.flag.lamber = TRUE; This option should be identical to what we have in the fortran version. So this is OK for the moment. |
olemke
commented
Sep 25, 2019
@erikssonpatrick, that fits with @m-brath and my conclusion. @m-brath and I want to do one more test of cdisort tomorrow with a realistic scenario. If that is successful, I'll remove the Fortran version and merge the PR. |
Allow reasonable differences between Fortran and C Disort.
Enable C disort by default.
Functions removed: dtauc_ssalbCalc2, phase_functionCalc2, phase_functionCalc, pmomCalc2, pmomCalc, surf_albedoCalc.
olemke
commented
Sep 30, 2019
The tests have shown that cdisort is in good agreement with the Fortran version. Thus, the Fortran code has been removed. |
This PR adds cdisort version 2.1.3 to the 3rdparty directory in ARTS.
The WSM DisortCalc now uses cdisort by default. For testing purposes, reverting to Fortran Disort is supported via a generic argument to DisortCalc.
The disort ARTS code has been cleaned up and all unused functions, as well as the experimental DisortCalcWithARTSSurface, have been removed.