GEOS-CHEM ERROR: Excessive fall velocity? STOP at CALC_FALLVEL, UCX_mod

[dyblove]

Your name

Yibo Dou

Your affiliation

PKU

What happened? What did you expect to happen?

Dear @yantosca, @ltmurray, I started a one-day simulation from start_date: [20300101, 00:00] to end_date: [20300102, 00:00] and fixed the meteorological data in 2015, but I encountered an error. I would like to know what I should do, and your help would be very important to me.
---> DATE: 2030/01/01 UTC: 00:00
HEMCO already called for this timestep. Returning.
Getting CH4 boundary conditions in GEOS-Chem from :SfcVMR_CH4

• DO_LINEAR_CHEM: Linearized chemistry at 2030/01/01 00:00
• LINOZ_CHEM3: Doing LINOZ
  ===============================================================================
  GEOS-CHEM ERROR: Excessive fall velocity?
  STOP at CALC_FALLVEL, UCX_mod
  

What are the steps to reproduce the bug?

I started a one-day simulation from start_date: [20300101, 00:00] to end_date: [20300102, 00:00] and fixed the meteorological data in 2015, but I encountered an error.

Please attach any relevant configuration and log files.

GC.log
geoschem_config.yml.txt
HEMCO_Config.rc.gmao_metfields.txt
HEMCO_Config.rc.txt
HISTORY.rc.txt

What GEOS-Chem version were you using?

14.5.0

What environment were you running GEOS-Chem on?

Other (please explain below)

What compiler and version were you using?

GCC 12.3.0

Will you be addressing this bug yourself?

Yes, but I will need some help

In what configuration were you running GEOS-Chem?

GCClassic

What simulation were you running?

Full chemistry

As what resolution were you running GEOS-Chem?

2×2.5

What meterology fields did you use?

MERRA-2

Additional information

No response

[ltmurray]

That is a conservative trap in the stratospheric chemistry mechanism that is often triggered when applying a restart file that is out of sync with the stratospheric dynamical conditions. You can just comment it out to allow the run to proceed. @sdeastham and @yantosca, should we make that the default behavior?

[yantosca]

@sdeastham and @yantosca, should we make that the default behavior?

I think we should consider making it default, as this has tripped up many users in the past:

https://github.com/geoschem/geos-chem/issues?q=is%3Aissue+stop+at+calc_fallvel

[dyblove]

That is a conservative trap in the stratospheric chemistry mechanism that is often triggered when applying a restart file that is out of sync with the stratospheric dynamical conditions. You can just comment it out to allow the run to proceed. @sdeastham and @yantosca, should we make that the default behavior?

Dear @ltmurray, thank you for your reply, but I don't understand which information in which file should I comment out?

[ltmurray]

Hi @dyblove, the output tells you the file that is triggering the error (ucx_mod.F90). Open that file, and search for the error message ("Excessive fall velocity"), and then you can comment out the logical trap that calls ERROR_STOP, which is what is causing the model to stop.