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.

[eamarais]

@yantosca, @ltmurray and @sdeastham, how about rather having this as an ERROR_STOP if after a certain amount of elapsed model time there is still excessive fall velocity? This would ensure we catch any issues that aren't associated with out-of-sync restart conditions. I'm encountering this issue with version 14.5.0 due to my restart conditions.

Alternately, to have a "spin-up" flag so that the model doesn't stop during model initialization? In a version 14.5.0 test run I did printing out "excessive fall velocity", but allowing the model to keep running, it took 28 model days for the fall velocity to reach acceptable levels, so an elapsed time approach wouldn't be practical.