Satellite diagnostic simulations show a gradual decrease in pressure day by day

[zpleo]

Your name

Zhang Peng

Your affiliation

Southern University of Science and Technology

What happened? What did you expect to happen?

I opened the satellite transit simulation in HISTORY.rc and set daily diagnostic output, but when I checked the SatDiagnPEdge in the output file, I found that the pressure of the first level of each day gradually decreased. The first day of each month was about 1000 hPa, but the second day was 500 hPa until the end of the month was 33 hPa, but the first day of the next month was 1000 hPa again. I would like to ask what is the reason for this. If I want to check the column average concentration of 815 hPa-215 hPa at the transit time of a certain pollutant every day, how can I achieve it?
Thank you for your help and reply

What are the steps to reproduce the bug?

Turn on satellite diagnostics and pressure margins

Please attach any relevant configuration and log files.

What GEOS-Chem version were you using?

14.4.3

What environment were you running GEOS-Chem on?

Local cluster

What compiler and version were you using?

gcc 4.8.5 ifort 18.0.5

Will you be addressing this bug yourself?

No

In what configuration were you running GEOS-Chem?

GCClassic

What simulation were you running?

Full chemistry

As what resolution were you running GEOS-Chem?

4×5

What meterology fields did you use?

MERRA-2

Additional information

No response

[msulprizio]

Thank for for reporting this @zpleo. The GCST does not validate this diagnostic so I am tagging the original developer @eamarais to see if they have encountered this issue.

[eamarais]

Hi @msulprizio and @zpleo, I didn't add the separate SatDiagnPEdge diagnostic. It was moved from the SatDiagn collection to a separate collection. Not sure who implemented this? @yantosca might know.

[yantosca]

Thanks @zpleo @msulprizio and @eamarais. We had to move the SatDiagnPEdge diagnostic to a different collection because netCDF files can only have one vertical dimension. You can't mix data that is placed on level edges and level centers into the same netCDF file.

I can try to replicate the error.

[zpleo]

@yantosca Thank you for your reply. Below is the SatDiagn setting in my HISTORY.rc. I also turned on THE SatDiagnEdge COLLECTION. The pressure operation results of the two are consistent. So how should I adjust the code to view the pressure distribution of the simulated concentration of pollutants every day? Because I found that taking October 2021 as an example, the concentration of PAN on level=1 on the 1st and 29th is 100 times different. I feel that if the simulated pressure distribution is consistent every day, it will not be so different. I found the same phenomenon in other months.

[zpleo]

@yantosca Hi, I moved the SatDiagnPEdge diagnostic to a new collection and re-ran the model but found that the simulation is the same as before, the surface to pressure layer is simulated to 0 on the 1st of each month but the next day the simulation starts from 500hPa again.

[eamarais]

Hi @zpleo , you could move it back to the original SatDiagn diagnostic. I originally implemented it in this diagnostic, as I anticipated most if not all users wouldn't need the top layer altitude, given most users require the satellite diagnostic output for layers in the troposphere and stratosphere.

[zpleo]

Hi@eamarais @yantosca ,sorry, there are some problems with my expression.I encountered an issue with the simulated height data. On the first day of each month, the simulated height is consistently at 1000 hPa from the surface to the top. However, on the second day, the simulated pressure index shows 500 hPa-0hPa, and on the last day, it drops to 30 hPa-0hPa. I would like to understand the cause of this phenomenon, as I am studying the concentration of substances during satellite transit times between 825 hPa and 215 hPa each day. So it is very important for me to correct this problem. Thank you for your reply and help

[hazel008]

Hi, I encountered the same issue in my NH3 simulation using GC Classic 14.4.3. Just wondering if this problem has been solved or not? Thanks!

[hazel008]

@msulprizio @yantosca @eamarais @zpleo Hi, I ran some test simulations and found that setting the frequency and duration of the restart file to daily magically solves this issue, although I haven't figured out why. See the attachment. I think it has something to do with resetting State_Diag%SatDiagnCount to zero in history_mod.F90.
SatDiagn_test.pptx

[yantosca]

Thanks @msulprizio @eamarais @zpleo for your patience. I was out of the office unexpectedly for a few days. I will look into this issue now.

[hazel008]

Hi, I believe the bug is in the following lines in history_mod.F90:

IF ( State_Diag%Archive_SatDiagnCount .and. DoWrite ) THEN
       State_Diag%SatDiagnCount = 0.0_f8
ENDIF

Here, the DoWrite variable (intended for SatDiagn) is actually overwritten by the value for Restart.

I've fixed this by introducing a new logical variable, DoWrite_SatDiagn, specifically for SatDiagn. Please see the difference between the modified and standard history_mod.F90 below:

2881,2882d2880
<     LOGICAL                          :: DoWrite_SatDiagn
2885,2886d2882
<     LOGICAL                          :: isSatDiagn
2907,2908d2902
<     DoWrite_SatDiagn    = .FALSE.
2932,2934d2925
<        isSatDiagn = ( TRIM( cName ) == 'SATDIAGN'            )
2958,2961d2948
<        IF (isSatDiagn .AND. DoWrite) DoWrite_SatDiagn = .TRUE.
3117,3121c3104,3106
<     IF ( State_Diag%Archive_SatDiagnCount .and. DoWrite_SatDiagn ) THEN
<          State_Diag%SatDiagnCount = 0.0_f8
---
>     IF ( State_Diag%Archive_SatDiagnCount .and. DoWrite ) THEN
>        State_Diag%SatDiagnCount = 0.0_f8
~                                                                                                                  
~                                

[eamarais]

Hi @yantosca, do you know when the below lines were added to the model? I don't have these in version 13.0.2 or 14.1.0, so perhaps this issue is only relevant to model version 14.4.3. My versions use the traditional "GOOD" variable approach that was used in the original ND51 diagnostic writing to bpch files. Just want to make sure that my group and others using earlier versions of the SatDiagn collection aren't affected by this bug.

IF ( State_Diag%Archive_SatDiagnCount .and. DoWrite ) THEN
State_Diag%SatDiagnCount = 0.0_f8
ENDIF 

[yantosca]

@eamarais: I think they came in a recent 14.4.x update. That is probably my bad.

@hazel008: Thanks for the fix! I will have some further updates for the satellite diagnostics. I realized that the SatDiagnPEDGE wasn't saving the top level (level 73, model top) so I have added some updates to fix that. I'll push a PR shortly.

[yantosca]

@eamarais: BTW, if you go to GitHub and look up any file and then click the "Blame" button, it will show the most recent commit that is associated with any line of code:

In this case it was my commit on July 10th of this year.

[yantosca]

@eamarais @zpleo @hazel008: I've added a fix in PR #2544. It basically implements the fix by @hazel008 but also adds a separate counter for the SatDiagnEdge collection.

[yantosca]

@zpleo @hazel008 @msulprizio @eamarais: This is now fixed by PR #2544, which will go into 14.5.1. We can now close out this issue.