Difference between revisions of "Bugs and fixes"

From Geos-chem
Jump to: navigation, search
(→‎GEOS-Chem 13)
 
(624 intermediate revisions by 7 users not shown)
Line 1: Line 1:
−
On this page we list the GEOS-Chem bugs that users have recently encountered, and how to fix them.
+
On this page we list the GEOS-Chem specific bugs and issues that users have recently encountered, and how to fix them.
  
−
== Problem w/ ND65 diagnostic and dynamic tropopause ==
+
== Bugs and fixes lists have now been migrated to Github ==
  
−
=== 10-Jun-2008 ===
+
We have been migrating bug reports to our GEOS-Chem issue tracker, which is located on our Github repository: https://github.com/geoschem/geos-chem/issues/.  We recommend that you also look through both the open and closed issues on this page, as your issue might be listed there.
  
−
'''''Yuxuan Wang (wang3@fas.harvard.edu) wrote:'''''
+
=== GEOS-Chem 13 ===
  
−
:It looks like that it's the dynamic tropopause in v8-01-01 that causes the unrealistically high AD65 values (prod and loss rate of chemical families). When I turn off the dynamic tropopause in input.geos, the model gives AD65 that's reasonable and also comparable to my previous simulations with code version 7.  I took a careful look of tropopause_mod.f, but couldn't find where the problem is.
+
{| border=1 cellspacing=0 cellpadding=5
 +
|-bgcolor="#CCCCCC"
 +
!Version
 +
!Released
 +
!colspan="2"|List of bugs and issues (now posted on the listed Github repository)
  
−
:Yuxuan
+
|-valign="top"
 +
|[[GEOS-Chem_model_development_priorities#13.3.0|13.3.0]]
 +
|TBD
 +
|[https://github.com/geoschem/geos-chem geoschem/geos-chem]
 +
|[https://github.com/geoschem/geos-chem/milestone/19 '''Milestone 13.3.0''']
  
−
'''''Philippe Le Sager (plesager3@seas.harvard.edu) wrote:'''''
+
|-valign="top"
 +
|[[GEOS-Chem_model_development_priorities#13.2.0|13.2.0]]
 +
|TBD
 +
|[https://github.com/geoschem/geos-chem geoschem/geos-chem]
 +
|[https://github.com/geoschem/geos-chem/milestone/18 '''Milestone 13.2.0''']
  
−
:I think I found the root of your problem with P/L diagnostic. The line 606 (subroutine do_diag_pl, in diag_pl_mod.f) :
+
|-valign="top"
 +
|[[GEOS-Chem 13.1.0|13.1.0]]
 +
|TBD
 +
|[https://github.com/geoschem/geos-chem geoschem/geos-chem]
 +
|[https://github.com/geoschem/geos-chem/milestone/17 '''Milestone 13.1.0''']
  
−
          ! Zero each "fake" ND65 prod/loss family for next iteration
+
|-valign="top"
−
          CSPEC(JLOOP,IFAM(N)) = 0.0d0
+
|[[GEOS-Chem 13.0.2|13.0.2]]
 +
|12 Apr 2021
 +
|[https://github.com/geoschem/geos-chem geoschem/geos-chem]
 +
|[https://github.com/geoschem/geos-chem/milestone/21?closed=1 '''Milestone 13.0.2''']
  
−
:is done too late in the code. Here is the full story:
+
|-valign="top"
 +
|[[GEOS-Chem 13.0.1|13.0.1]]
 +
|23 Mar 2021
 +
|[https://github.com/geoschem/geos-chem geoschem/geos-chem]
 +
|[https://github.com/geoschem/geos-chem/milestone/20?closed=1 '''Milestone 13.0.1''']
  
−
:At each time step, the CSPEC_FULL array is used to initialize the CSPEC array before entering SMVGEAR. CSPEC_FULL is filled with CSPEC after SMVGEAR. So it should account for the line 606 above, but it does not since the family P/L diagnostic is done after CSPEC_FULL has been updated.
+
|-valign="top"
 +
|width="80px"|[[GEOS-Chem 13.0.0|13.0.0]]
 +
|width="100px"|18 Mar 2021
 +
|width="200px"|[https://github.com/geoschem/geos-chem geoschem/geos-chem]
 +
|width="400px"|[https://github.com/geoschem/geos-chem/milestone/8?closed=1 '''Milestone 13.0.0''']
  
−
:The fix is easy. In CHEMDR.F you need to move the call to SAVE_FULL_TROP to the end of the routine, so CSPEC_FULL is updated after the P/L diagnostic. You can look at my: ~phs/Code.current/chemdr.f
+
|}
  
−
:If you could let me know if that fix you problem with a quick run, that would be perfect
+
=== GEOS-Chem 12 ===
−
:Thanks,
+
−
:-Philippe
+
  
−
'''''Yuxuan Wang (wang3@fas.harvard.edu) wrote:'''''
+
{| border=1 cellspacing=0 cellpadding=5
 +
|-bgcolor="#CCCCCC"
 +
!Version
 +
!Released
 +
!colspan="2"|List of bugs and issues (now posted on the listed Github repository)
  
−
:I just did a one-day test and it worked! P/L diagnostics now are at the right order of magnitude after I turned on the variable tropopause. That's indeed the fix. Thank you!!
+
|-valign="top"
−
:Yuxuan
+
|[[GEOS-Chem 12#12.9.3|12.9.3]]
 +
|06 Aug 2020
 +
|[https://github.com/geoschem/geos-chem geoschem/geos-chem]
 +
|[https://github.com/geoschem/geos-chem/milestone/16?closed=1 '''Milestone 12.9.3''']
  
−
This fix will go into the next release of GEOS-Chem.
+
|-valign="top"
 +
|[[GEOS-Chem 12#12.9.2|12.9.2]]
 +
|24 Jul 2020
 +
|[https://github.com/geoschem/geos-chem geoschem/geos-chem]
 +
|[https://github.com/geoschem/geos-chem/milestone/15?closed=1 '''Milestone 12.9.2''']
  
−
--[[User:Bmy|Bob Y.]] 16:17, 3 June 2008 (EDT)
+
|-valign="top"
 +
|[[GEOS-Chem 12#12.9.1|12.9.1]]
 +
|17 Jul 2020
 +
|[https://github.com/geoschem/geos-chem geoschem/geos-chem]
 +
|[https://github.com/geoschem/geos-chem/milestone/14?closed=1 '''Milestone 12.9.1''']
  
 +
|-valign="top"
 +
|[[GEOS-Chem 12#12.9.0|12.9.0]]
 +
|17 Jul 2020
 +
|[https://github.com/geoschem/geos-chem geoschem/geos-chem]
 +
|[https://github.com/geoschem/geos-chem/milestone/10?closed=1 '''Milestone 12.9.0''']
  
−
== Negative tracer in routine WETDEP because of negative RH ==
+
|-valign="top"
−
+
|[[GEOS-Chem 12#12.8.2|12.8.2]]
−
=== 1-May-2008 ===
+
|27 May 2020
 +
|[https://github.com/geoschem/geos-chem geoschem/geos-chem]
 +
|[https://github.com/geoschem/geos-chem/milestone/13?closed=1 '''Milestone 12.8.2''']
  
−
See this post: [[GEOS-5 issues#Small negative RH value in 20060206.a6.2x25 file]]
+
|-valign="top"
 +
|[[GEOS-Chem 12#12.8.1|12.8.1]]
 +
|21 May 2020
 +
|[https://github.com/geoschem/geos-chem geoschem/geos-chem]
 +
|[https://github.com/geoschem/geos-chem/milestone/12?closed=1 '''Milestone 12.8.1''']
  
−
Fixes are available at ftp://ftp.as.harvard.edu/pub/exchange/phs/GEOS-Chem-UPDATE/
+
|-valign="top"
 +
|[[GEOS-Chem 12#12.8.0|12.8.0]]
 +
|04 Mar 2020
 +
|[https://github.com/geoschem/geos-chem geoschem/geos-chem]
 +
|[https://github.com/geoschem/geos-chem/milestone/7?closed=1 '''Milestone 12.8.0''']
  
−
--[[User:Plesager|phs]] 16:31, 6 June 2008 (EDT)
+
|-valign="top"
 +
|[[GEOS-Chem 12#12.7.2|12.7.2]]
 +
|09 Mar 2020
 +
|[https://github.com/geoschem/geos-chem geoschem/geos-chem]
 +
|[https://github.com/geoschem/geos-chem/milestone/11?closed=1 '''Milestone 12.7.2''']
  
−
== Negative tracer in routine WETDEP ==
+
|-valign="top"
−
+
|[[GEOS-Chem 12#12.7.1|12.7.1]]
−
=== 17-Apr-2007 ===
+
|19 Feb 2020
 +
|[https://github.com/geoschem/geos-chem geoschem/geos-chem]
 +
|[https://github.com/geoschem/geos-chem/milestone/9?closed=1 '''Milestone 12.7.1''']
  
−
'''''Dylan Millet (dbm@umn.edu) wrote:'''''
+
|-valign="top"
−
:I'm having a run die consistently at the same time (October 1, 2005; first time step of the month) in large-scale wetdep, with an STT element < 0.
+
|[[GEOS-Chem 12#12.7.0|12.7.0]]
−
:* Platform: Linux cluster
+
|03 Feb 2020
−
:* Threads: 8
+
|[https://github.com/geoschem/geos-chem geoschem/geos-chem]
−
:* Version: v7-4-13 out of the box.
+
|[https://github.com/geoschem/geos-chem/milestone/4?closed=1 '''Milestone 12.7.0''']
−
:* GEOS4, 4x5, 30L, full chemistry
+
−
:* IFORT 10.1
+
  
−
:In Section 6 (No Downward Precip) of wetscav_mod.f, subroutine safety is getting called.
+
|-valign="top"
−
    WETDEP - STT < 0 at    1   1  29 for tracer    7 in area    6
+
|[[GEOS-Chem 12#12.6.3|12.6.3]]
 +
|25 Nov 2019
 +
|[https://github.com/geoschem/gchp geoschem/gchp]
 +
|[https://github.com/geoschem/gchp/milestone/2?closed=1 '''Milestone 12.6.3''']
  
−
:(First of all it seems odd to do wetdep for L=29, this is 63 km up). Have you seen anything like this? I ran for the whole year starting Jan 1 successfully until this point.
+
|-valign="top"
 +
|[[GEOS-Chem 12#12.6.2|12.6.2]]
 +
|15 Nov 2019
 +
|[https://github.com/geoschem/geos-chem geoschem/geos-chem]
 +
|[https://github.com/geoschem/geos-chem/milestone/6?closed=1 '''Milestone 12.6.2''']
  
−
:... By the way, the problem persists when I turn off chemistry altogether.  
+
|-valign="top"
 +
|[[GEOS-Chem 12#12.6.1|12.6.1]]
 +
|28 Oct 2019
 +
|[https://github.com/geoschem/geos-chem geoschem/geos-chem]
 +
|[https://github.com/geoschem/geos-chem/milestone/5?closed=1 '''Milestone 12.6.1''']
  
−
'''''Philippe Le Sager (plesager@seas.harvard.edu) replied:'''''  
+
|-valign="top"
 +
|width="80px"|[[GEOS-Chem 12#12.6.0|12.6.0]]
 +
|width="100px"|18 Oct 2019
 +
|width="200px"|[https://github.com/geoschem/geos-chem geoschem/geos-chem]
 +
|width="400px"|[https://github.com/geoschem/geos-chem/milestone/2?closed=1 '''Milestone 12.6.0''']
  
−
:I used your restart file and the same input.geos (w/ chemistry on and off). My code went thru without problem.  I tried both Sun Studio and Ifort 9 compilers, and the later on two different machines (altix and ceres). I used v7-04-13 and v8-01-01. I never reproduced your error.
+
|}
  
−
:We just got the new Ifort 10, and tried it too. I run v8-01-01 without an error.  But when I tried v7-04-13, I finally reproduced your error, with the exact same negative values!
+
== Bugs and fixes in older GEOS-Chem versions ==
  
−
:In other words: the bug happens with IFort 10 and v7-04-13 only.
+
For a complete list of bugs and fixes in older GEOS-Chem versions, please see:
  
−
:Also, have a look at this [[Aerosol_thermodynamical_equilibrium#ISORROPIA|recent development]].  This is not the reason for your bug (I tried v8 w/ ifort 10 and isorropia -like v7-04-13- and it did not crash), but using RPMARES instead of Isorropia may be a way to fix it.
+
*[[Bugs and fixes in GEOS-Chem 12.0.0 to 12.5.0]]
 +
*[[Bugs and fixes in GEOS-Chem v9, v10, and v11]]
 +
*[[Bugs and fixes in GEOS-Chem v7 and v8]]
  
−
:... More about the Ifort 10 / v7-04-13 issue.  When I wanted to debug with TotalView, I could not reproduce the bug anymore.... because I simply suppress any optimization.  So, I did more test and found that if the default -O2 optimization is used, GEOS-Chem crashes.  But it works fine with -O1. It is hard to tell what happens, since only the emissions step is done between reading the restart file and the crash.
+
--[[User:Bmy|Bob Yantosca]] ([[User talk:Bmy|talk]]) 14:23, 22 March 2021 (UTC)
−
 
+
−
:Bob and I will further test Ifort 10 for optimization on our machines. Maybe we will find something... For the time being, you may have to switch to -O1, at least for the run that crashes. You will find the optimization flag at the beginning of the Makefile.ifort.
+
−
 
+
−
Long story short: This appears to be an optimization issue with IFORT 10 and v7-04-13.  Upgrading to [[GEOS-Chem_versions_under_development#v8-01-01|GEOS-Chem v8-01-01]] should solve this problem.
+
−
 
+
−
--[[User:Bmy|Bmy]] 10:38, 17 April 2008 (EDT)
+
−
 
+
−
== ISORROPIA and RPMARES ==
+
−
 
+
−
=== 11-Apr-2008 ===
+
−
 
+
−
Please see the discussion about the bugs & fixes for ISORROPIA and RPMARES on the Code Developer's Forum for [[Aerosol thermodynamical equilibrium]].
+
−
 
+
−
== NaN's in SMVGEAR ==
+
−
 
+
−
=== 05-Jul-2007 ===
+
−
 
+
−
'''''Lok Lamsal (lok.lamsal@fizz.phys.dal.ca)wrote:'''''
+
−
:I ran into a problem while running GEOS-4, version v7-04-09, at 2x2.5. The simulation stops on 15th July 2006 with different error messages on two of our machines tuque and beret. One of the error messages on tuque is like this:
+
−
 
+
−
  sum of rrate =  Infinity
+
−
  SMVGEAR: CNEW is NaN!
+
−
  Species index :            1
+
−
  Grid Box      :          121          15          1
+
−
  STOP in smvgear.f!
+
−
      - CLEANUP: deallocating arrays now...
+
−
forrtl: severe (174): SIGSEGV, segmentation fault occurred
+
−
 
+
−
:And on beret the message is like this:
+
−
 
+
−
      - CLEANUP: deallocating arrays now...
+
−
  forrtl: severe (174): SIGSEGV, segmentation fault occurred
+
−
  Image              PC                Routine            Line
+
−
  Source
+
−
  geos_4_nv          400000000059EA10  Unknown              Unknown
+
−
  Unknown
+
−
  libguide.so        200000000039C1A0  Unknown              Unknown
+
−
  Unknown
+
−
  etc.
+
−
</pre>
+
−
 
+
−
:The message which is repeated in either case is like this:
+
−
 
+
−
  SMVGEAR: DELT= 9.96E-16 TOO LOW DEC YFAC. KBLK, KTLOOP, NCS, TIME, TIMREMAIN, YFAC, EPS =
+
−
 
+
−
:Could you suggest me what the problem could be? Just to inform you: while trying to figure out the problem, I noticed from Bastien that he did not have problem on that day with version v7-04-10, which stopped on September 13 2006.
+
−
 
+
−
'''''Bob Yantosca (yantosca@seas.harvard.edu) replied:'''''
+
−
:I think there is a division by zero somewhere that is causing SMVGEAR to choke.  It could be a couple of things:
+
−
 
+
−
:(1) Make sure that in your In a6_read_mod.f (routine READ_A6) you have the following code to prevent Q from going to zero.  This can make logarithms blow up in other places in the code:
+
−
 
+
−
 
+
−
          !--------------------------------
+
−
          ! Q: 6-h avg specific humidity
+
−
          ! (GEOS-4 only)
+
−
          !--------------------------------
+
−
          CASE ( 'Q' )
+
−
            READ( IU_A6, IOSTAT=IOS ) XYMD, XHMS, Q3
+
−
            IF ( IOS /= 0 ) CALL IOERROR( IOS, IU_A6, 'read_a6:16' )
+
−
   
+
−
            IF ( CHECK_TIME( XYMD, XHMS, NYMD, NHMS ) ) THEN
+
−
                IF ( PRESENT( Q ) ) CALL TRANSFER_3D( Q3, Q )
+
−
                NFOUND = NFOUND + 1
+
−
   
+
−
                ! NOTE: Now set negative Q to a small positive #
+
−
                ! instead of zero, so as not to blow up logarithms
+
−
                ! (bmy, 9/8/06)
+
−
                WHERE ( Q < 0d0 ) Q = 1d-32
+
−
            ENDIF
+
−
 
+
−
:(2) In fvdas_convect_mod.f, make SMALLEST a smaller number (i.e. 1d-60):
+
−
 
+
−
    !=================================================================
+
−
    ! MODULE VARIABLES
+
−
    !=================================================================
+
−
   
+
−
    ! Variables
+
−
    INTEGER            :: LIMCNV              ! Constants
+
−
    LOGICAL, PARAMETER :: RLXCLM  = .TRUE.
+
−
    REAL*8,  PARAMETER :: CMFTAU  = 3600.d0
+
−
    REAL*8,  PARAMETER :: EPS      = 1.0d-13     
+
−
    REAL*8,  PARAMETER :: GRAV    = 9.8d0
+
−
    !-------------------------------------------------------
+
−
    ! Prior to 12/19/06:
+
−
    ! Make SMALLEST smaller (bmy, 12/19/06)
+
−
    !REAL*8,  PARAMETER :: SMALLEST = 1.0d-32
+
−
    !-------------------------------------------------------
+
−
    REAL*8,  PARAMETER :: SMALLEST = 1.0d-60
+
−
    REAL*8,  PARAMETER :: TINYALT  = 1.0d-36         
+
−
    REAL*8,  PARAMETER :: TINYNUM  = 2*SMALLEST
+
−
 
+
−
:(3) In "fvdas_convect_mod.f", avoid division by zero in routine CONVTRAN:
+
−
 
+
−
            IF ( CDIFR > 1.d-6 ) THEN
+
−
   
+
−
                ! If the two layers differ significantly.
+
−
                ! use a geometric averaging procedure
+
−
                CABV = MAX( CMIX(I,KM1), MAXC*TINYNUM, SMALLEST )
+
−
                CBEL = MAX( CMIX(I,K),  MAXC*TINYNUM, SMALLEST )
+
−
  !-----------------------------------------------------------------
+
−
  !  Prior to 12/19/06:
+
−
  ! Avoid division by zero (bmy, 12/19/06)
+
−
  !                  CHAT(I,K) = LOG( CABV / CBEL)
+
−
  !    &                      /  ( CABV - CBEL)
+
−
  !    &                      *    CABV * CBEL
+
−
  !-----------------------------------------------------------------
+
−
   
+
−
                ! If CABV-CBEL is zero then set CHAT=SMALLEST
+
−
                ! so that we avoid div by zero (bmy, 12/19/06)
+
−
                IF ( ABS( CABV - CBEL ) > 0d0 ) THEN
+
−
                  CHAT(I,K) = LOG( CABV / CBEL )
+
−
  &                        /    ( CABV - CBEL )
+
−
  &                        *      CABV * CBEL
+
−
                ELSE
+
−
                  CHAT(I,K) = SMALLEST
+
−
                ENDIF
+
−
   
+
−
            ELSE                         
+
−
                ! Small diff, so just arithmetic mean
+
−
                CHAT(I,K) = 0.5d0 * ( CMIX(I,K) + CMIX(I,KM1) )
+
−
            ENDIF
+
−
 
+
−
:(4) Also I had to rewrite the parallel DO loops in the routine HACK_CONV since this was causing some kind of a memory fault.
+
−
 
+
−
:You may just want to get the most recent version of fvdas_convect_mod.f, which has all of these fixes installed. See:
+
−
 
+
−
  ftp ftp.as.harvard.edu
+
−
  cd pub/exchange/bmy
+
−
  get fvdas_convect_mod.f
+
−
 
+
−
:So I would recommend trying to implement these fixes and see if this solves your problem.
+
−
 
+
−
:NOTE: These fixes have been introduced into GEOS-Chem v7-04-10.
+
−
 
+
−
== regrid_1x1_mod.f ==
+
−
 
+
−
=== 16 Oct 2007 ===
+
−
 
+
−
From Mike Barkley (mbarkley@staffmail.ed.ac.uk)
+
−
 
+
−
<blockquote>
+
−
I think I've found an error in the regrid_1x1_mod.f subroutine (attached in the text file):
+
−
 
+
−
<pre>
+
−
SUBROUTINE REGRID_MASS_TO_2x25( I1, J1, L1, IN, I2, J2, OUT )
+
−
</pre>
+
−
 
+
−
There is a do loop over longitude with the upper limit defined as the input latitude (J1) instead what should (?) be the output longitude (I2) - I've indicated where this in the program, Which is correct? We didn't notice this until we were running multi-processor 2x2.5 simulations on different servers.
+
−
 
+
−
The bug was:
+
−
 
+
−
<pre>
+
−
  !-----------------------
+
−
  ! Non-polar latitudes
+
−
  !-----------------------
+
−
  DO J = 2, J2-1   
+
−
    ...         
+
−
    DO I = 1, J1
+
−
</pre>
+
−
 
+
−
which needs to be replaced by:
+
−
 
+
−
<pre>
+
−
  !-----------------------
+
−
  ! Non-polar latitudes
+
−
  !-----------------------
+
−
  DO J = 2, J2-1   
+
−
    ...         
+
−
    DO I = 1, I1
+
−
</pre>
+
−
</blockquote>
+
−
 
+
−
This bug has now been fixed in [[wiki:geos-chem:dev_forum|GEOS-Chem v7-04-13]].
+
−
 
+
−
== smvgear.f ==
+
−
 
+
−
=== 02 Nov 2007 ===
+
−
 
+
−
'''''Bob Yantosca (yantosca@seas.harvard.edu) wrote'''''
+
−
 
+
−
:Some of you have reported a weird error in SMVGEAR that causes GEOS-Chem simulations to die unexpectedly.  The main symptom of this error is that concentrations of some species (e.g CO) appear to go to zero, while other species (e.g. Ox) seem to reach unphysically high values, all within a single chemistry timestep.  Then the simulation dies shortly thereafter.
+
−
 
+
−
:May Fu and Philippe Le Sager have isolated the cause of the problem.  They found that in some instances it is possible (e.g. due to locally low OH) to get into a regime where the first derivative of a species goes very negative during SMVGEAR's internal iteration loop.  This then causes the new species concentration to be negative.  This can sometimes happen even if the local & global error tolerance checks have passed.  Then upon exiting the internal iteration loop, SMVGEAR would automatically reset any negative species concentrations to zero (actually a small positive number like 1e-99).  A species with zero concentration can adversely affect other species within the SMVGEAR solver process.  Furthermore, sometimes these zero concentrations were propagating out of SMVGEAR and into the STT tracer array, which caused problems in other areas of the code.
+
−
 
+
−
:May & Philippe implemented a fix into the file "smvgear.f" which does the following: If a negative species concentration value is found during an internal iteration, then we don't set it to zero.  We instead reduce the internal iteration timestep and do another iteration (i.e. re-evaluate the Jacobian matrix) to solve for the new species concentration.  This process is repeated until SMVGEAR converges onto a non-negative solution.  May & Philippe also added an extra error trap to stop the simulation if any negative species concentrations still persist upon exiting the subroutine.  So the entire process should now be more robust.
+
−
 
+
−
:You may download the updated "smvgear.f" file from our anonymous FTP site:
+
−
 
+
−
<pre>
+
−
  ftp ftp.as.harvard.edu
+
−
  cd pub/geos-chem/patches/v7-04-12
+
−
  get README
+
−
  get smvgear.f
+
−
</pre>
+
−
 
+
−
:Then copy the "smvgear.f" file to your own source code directory and recompile.  Please see the README file for more information on how to locate the places in "smvgear.f" that were modified.
+
−
 
+
−
:This is not really a "bug" but more of a "design flaw" in the original SMVGEAR package.
+
−
 
+
−
 
+
−
This bug has now been fixed in GEOS-Chem [[wiki:geos-chem:dev_forum|GEOS-Chem v7-04-13]].
+

Latest revision as of 13:56, 14 April 2021

On this page we list the GEOS-Chem specific bugs and issues that users have recently encountered, and how to fix them.

Bugs and fixes lists have now been migrated to Github

We have been migrating bug reports to our GEOS-Chem issue tracker, which is located on our Github repository: https://github.com/geoschem/geos-chem/issues/. We recommend that you also look through both the open and closed issues on this page, as your issue might be listed there.

GEOS-Chem 13

Version Released List of bugs and issues (now posted on the listed Github repository)
13.3.0 TBD geoschem/geos-chem Milestone 13.3.0
13.2.0 TBD geoschem/geos-chem Milestone 13.2.0
13.1.0 TBD geoschem/geos-chem Milestone 13.1.0
13.0.2 12 Apr 2021 geoschem/geos-chem Milestone 13.0.2
13.0.1 23 Mar 2021 geoschem/geos-chem Milestone 13.0.1
13.0.0 18 Mar 2021 geoschem/geos-chem Milestone 13.0.0

GEOS-Chem 12

Version Released List of bugs and issues (now posted on the listed Github repository)
12.9.3 06 Aug 2020 geoschem/geos-chem Milestone 12.9.3
12.9.2 24 Jul 2020 geoschem/geos-chem Milestone 12.9.2
12.9.1 17 Jul 2020 geoschem/geos-chem Milestone 12.9.1
12.9.0 17 Jul 2020 geoschem/geos-chem Milestone 12.9.0
12.8.2 27 May 2020 geoschem/geos-chem Milestone 12.8.2
12.8.1 21 May 2020 geoschem/geos-chem Milestone 12.8.1
12.8.0 04 Mar 2020 geoschem/geos-chem Milestone 12.8.0
12.7.2 09 Mar 2020 geoschem/geos-chem Milestone 12.7.2
12.7.1 19 Feb 2020 geoschem/geos-chem Milestone 12.7.1
12.7.0 03 Feb 2020 geoschem/geos-chem Milestone 12.7.0
12.6.3 25 Nov 2019 geoschem/gchp Milestone 12.6.3
12.6.2 15 Nov 2019 geoschem/geos-chem Milestone 12.6.2
12.6.1 28 Oct 2019 geoschem/geos-chem Milestone 12.6.1
12.6.0 18 Oct 2019 geoschem/geos-chem Milestone 12.6.0

Bugs and fixes in older GEOS-Chem versions

For a complete list of bugs and fixes in older GEOS-Chem versions, please see:

--Bob Yantosca (talk) 14:23, 22 March 2021 (UTC)

Retrieved from "https://wiki.seas.harvard.edu/geos-chem/index.php?title=Bugs_and_fixes&oldid=49385"