Question regarding COSP and WRF

[George Priftis]

Hi,

I intend to use the COSP to simulate what CLOUDSAT would observe within the maritime boundary layer. I have been trying to use COSPv2 with WRF output but I haven't been successful. Is there any example process or steps that I could follow?

Sincerely,

George

[Roger Marchand]

Dear George,

As no one appears to have answered your email, I presume that no one on this list has implemented COSP2 in WRF ...  

Is there anybody on the list here who has implemented COSP1.4 ?    There are a couple publications out there where COSP has been used with WRF, so it has been done.   (if no-one replies you might try to contact authors of some of these papers, directly).

I am not a WRF user, but alternatively, perhaps you can explain a bit more about where you are running into problems?  Perhaps I (or others) who have used COSP2 can offer some ideas.  A basic question / good starting point is whether you been able to run (and test the output from) the example driver program that comes with COSP2?   

Regards,

Roj.

[dsw...@ucar.edu]

Greetings George,

Sorry for the delayed response.

As Roj mentioned, COSP2 comes with an example offline driver, which is driven by UKMO data. We don't have any "working practices" for how to install COSP for offline use, just the driver as an example. A good starting point would be to identify the inputs needed by the cloudsat simulator to produce the diagnostics you are interested in and which fields you have available in your WRF output. One thing I can say in general is that COSP requires many non-standard fields to be run offline, but to what degree somewhat depends on what diagnostics you are after.

Cheers,

Dustin

[George Priftis]

Thank you for your answer Roj. I have installed the COSP2 successfully. However, I can only run "./cosp2_test cosp2_input_nl.txt" because when I am running it with the namelist "cosp2_input_nl.um_global.txt" I am getting a segmentation fault. Additionally, the python script "compare_to_kgo.py" is also running but I have an error that some of the differences are larger than the tolerances. I haven't made any changes in the script for installation or testing.

I guess working with older version COSP1.4 might be easier since it's already been done. I'll look for those publications and contact the authors. That's a great idea!

 
Sincerely,

George

[George Priftis]

Thank you for your response Dustin. I am actually looking  to characterize low-level oceanic clouds so parameters like radar reflectivity factor profile, cloud height, cloud water content and surface precipitation. By looking at the example provided to test the MODIS simulator, looked like there are indeed many fields that needs to be provided. I guess the "test_modis_simulator.F90" script might be a good way to start.

Sincerely,

George

[Edward Gryspeerdt]

Hi George,

What kind of resolution are you running WRF at? If you are a high enough resolution that you don't need the subcolumn generator, I have a version of quickbeam (which the COSP radar simulator is based on) that is comparable to COSP v2 and has python bindings.

Ed

------

Edward Gryspeerdt

Grantham Institute, Imperial College London

[George Priftis]

Hi Ed, 

I am running the WRF at 1km resolution for the inner domain. It would be great if I could leverage your quickbeam version with Python bindings. 

Sincerejy,

George

[dsw...@ucar.edu]

Hi George,

I would stay away from test_modis_simulator.F90, and anything within the "unit_testing" directory. (This directory contains old code from the simulator developers for individual simulator testing, which predates the current testing provided with cosp2.)

Start with driver/src/cosp2_test.F90. This reads in sample input, sets up the input/output, and calls cosp_simulator(). You will need to mirror this process with your WRF data. The step setting up the input (two) and output (one) types is where you will need to connect your data with what cosp requires. One input type contains the model-state (e.g. temp, pres, humidity, etc...), and the other contains the derived optical description (e.g. optical-depth, radar reflectivity, lidar backscatter coefficients, etc...). There is a routine, subsample_and_optics(), provided with the offline driver to perform this mapping from the microphysical fields (e.g. cloud mixing-ratios, effective radii, ...) to the derived optical inputs. This is where you will need to determine what microphysical information you have from WRF and what microphysical information you want to provide to the instrument simulators.

Hopefully this provides a starting point. Feel free to reach out if you have specific questions.

Cheers,

Dustin

[George Priftis]

Hi Dustin,

Thank you for your detailed answer. This is definitely very helpful! 

Thank you,

George