Difference between revisions of "GCHP v11-02"
(→C preprocessor inserting GNU compiler version 6.1.0 information text into MAPL_COMMS___.f90) |
(→GCHP Version Features) |
||
Line 57: | Line 57: | ||
== GCHP Version Features == | == GCHP Version Features == | ||
+ | |||
+ | === v11-02f === | ||
+ | |||
+ | See also [[GEOS-Chem_v11-02#v11-02f|GEOS-Chem Classic v11-02f]]. | ||
+ | |||
+ | {| border=1 cellspacing=0 cellpadding=5 | ||
+ | |-bgcolor="#CCCCCC" | ||
+ | !width="500px"|Feature | ||
+ | !width="200px"|Submitted by | ||
+ | !width="80px"|Type | ||
+ | !width="200px"|Status | ||
+ | |||
+ | |- | ||
+ | !colspan="4" bgcolor="#CCFFFF"|Features affecting the full-chemistry benchmark simulation: | ||
+ | |||
+ | |-valign="top" | ||
+ | |Bug fix to turn off debug flags by default when compiling with gfortran | ||
+ | |Lizzie Lundgren (GCST) | ||
+ | |Bug fix | ||
+ | |Pending validation | ||
+ | |||
+ | |-valign="top" | ||
+ | |Updates associated with compatibility with GEOS-Chem v11-02f core | ||
+ | |Lizzie Lundgren (GCST) | ||
+ | |Structural | ||
+ | |Pending validation | ||
=== v11-02e === | === v11-02e === | ||
Line 74: | Line 100: | ||
|-valign="top" | |-valign="top" | ||
|Assorted diagnostic improvements | |Assorted diagnostic improvements | ||
+ | |Lizzie Lundgren (GCST) | ||
+ | |Structural | ||
+ | |Pending validation | ||
+ | |||
+ | |-valign="top" | ||
+ | |Updates associated with compatibility with GEOS-Chem v11-02e core | ||
|Lizzie Lundgren (GCST) | |Lizzie Lundgren (GCST) | ||
|Structural | |Structural |
Revision as of 20:20, 31 May 2018
Contents
- 1 Overview
- 2 Version Mapping and Status
- 3 GCHP Version Features
- 4 Validation
- 5 Previous HP issues now resolved in GEOS-Chem v11-02
- 5.1 First and last daily output files missing hourly data
- 5.2 LWI import incorrectly regridded in GCHP
- 5.3 MPICH MPI implementation not readily usable with GCHP
- 5.4 MPI_Wait error when running at coarse resolution with high-resolution input data
- 5.5 HEMCO restart variables are not read into ExtData
- 5.6 Some State_Met arrays never set beyond initialization to zero
- 5.7 Day-of-week scale factors not read in by ExtData
- 5.8 GFortran compiler not compatible with GCHP
- 5.9 Restart file must contain all advected species
- 5.10 Bug in handling of monthly climatology in December
- 5.11 Compile failure if using certain versions of gmake
- 5.12 Simulation crashes if started prior to the first MMDD in climatology files
- 5.13 Rn-Pb-Be7 simulation not functional in GCHP in v1.0.0
- 6 Outstanding HP issues not yet resolved in GEOS-Chem v11-02
- 6.1 Segmentation fault if using volcano emissions with NetCDF 4.2 and higher versions on some systems
- 6.2 Resolution dependency of emissions
- 6.3 Time can only flow forward in MAPL
- 6.4 Timestep midpoint cos(SZA) is set to cos(SZA) at start of timestep
- 6.5 GFortran + MVAPICH2 runs hang if using multiple nodes
- 6.6 GCHP is incompatible with GNU compiler v6 due to use of ESMF v5
- 6.7 C preprocessor inserting GNU compiler version 6.1.0 information text into MAPL_COMMS___.f90
Overview
GEOS-Chem v11-02 with the high performance option enabled (GCHP) features the same science as GEOS-Chem using the standard "classic" capability (GCC) but operates on a cubed-sphere grid and is parallelized using a message-passing interface (MPI) implementation. GCHP improves upon GCC by (1) enabling more accurate transport, and (2) providing efficient scaling making finer resolution global simulations possible.
Running GEOS-Chem with the high performance option requires use of source code from two repositories maintained under version control. This page documents the mapping between the two repositories as well as the features and bug fixes added specifically to the HP-only repository called GCHP. Updates to the GCHP repository are maintained on this page separately from the primary GEOS-Chem v11-02 wiki page because they are primarily structural updates. Scientific updates from the community will continue to be implemented in the primary GEOS-Chem repository and documented on the GEOS-Chem v11-02 wiki page.
Version Mapping and Status
For GEOS-Chem v11-02b and v11-02c we used a separate version numbering system for the HP-only repository, specifically of form vX.Y.Z. Starting in v11-02d we are simplifying the version numbering system to use the same version numbering as GEOS-Chem Classic. The version numbering appears as tags in the master branch of the repository. For example, starting in v11-02d you can access source code for GCHP by checking out the GC_Bleeding_Edge and GCHP repository master branches and then checking out tag "v11-02d". Similarly, you can download a GCHP run directory for v11-02d by checking out the UT_Bleeding_Edge repository and checking out tag "v11-02d".
The table below maps GEOS-Chem version tags and status with the compatible version tags of the high performance option (GCHP) and unit tester (UT). The initial version, v1.0.0, which is not compatible with v11-02, is included for a complete history.
GCHP version | Status | Validation |
---|---|---|
v11-02e | In Development | No benchmark is planned for this version |
v11-02d | Recommended | No benchmark was performed for this version |
v11-02c | Complete | No benchmark was performed for this version |
v11-02b | Complete |
Benchmarks approved by GCSC:
|
GCHP_v1.0.0 | Complete | No benchmark was performed for this version |
Currently GCHP is not a git sub-module of the primary GEOS-Chem repository so we rely on git tags to manually map between the two code bases. All versions listed in the above table appear as git tags within the master branches of the repositories linked to in the table heading. This will likely change in the future when every download of GEOS-Chem is expected to include the high performance capability. Until then, please refer to this page to ensure that you are using the correct repository versions to run your simulations.
To checkout a git tag simply type:
git checkout tags/tag_name
GCHP Version Features
v11-02f
See also GEOS-Chem Classic v11-02f.
Feature | Submitted by | Type | Status | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Features affecting the full-chemistry benchmark simulation: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Bug fix to turn off debug flags by default when compiling with gfortran | Lizzie Lundgren (GCST) | Bug fix | Pending validation | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Updates associated with compatibility with GEOS-Chem v11-02f core | Lizzie Lundgren (GCST) | Structural | Pending validation
v11-02eSee also GEOS-Chem Classic v11-02e.
--Lizzie Lundgren (talk) 22:50, 5 March 2018 (UTC) v11-02dSee also GEOS-Chem Classic v11-02d.
--Lizzie Lundgren (talk) 15:54, 17 October 2017 (UTC) v11-02cThis benchmark was not formally benchmarked. See also GEOS-Chem Classic v11-02c.
--Lizzie Lundgren (talk) 15:55, 17 October 2017 (UTC) v11-02bPlease see the following resources for complete information on validation of this version:
See also GEOS-Chem Classic v11-02b. Please note that diagnostics are not yet available in this version and GCHP benchmark materials are therefore limited to concentration comparisons.
v1.0.0GEOS-Chem with HP v1.0.0 is a preliminary version of the HP option in GEOS-Chem that is compatible with a version of GEOS-Chem base code built off of v11-01. As an initial version of GCHP it is included on this page for completeness even though it is not compatible with GEOS-Chem v11-02. Note that v1.0.0 did not undergo a formal benchmark review by the GEOS-Chem Steering Committee. Please see GEOS-Chem v11-01 HP validation wiki page for information about the internal benchmark of this version performed by the GCHP Development Team.
In the pipeline
ValidationIn this section we provide information about the benchmarks and tests that we have done to validate the high performance option of GEOS-Chem v11-02. 1-month and 1-year benchmarksFor complete information about the benchmark simulations used to validate GEOS-Chem v11-02, please see our GEOS-Chem v11-02 benchmark history wiki page. Timing testsOur wiki page for submitting GCHP timing results is now available. Please visit GEOS-Chem HP Timing Tests and share your timing information collected on your system. Previous HP issues now resolved in GEOS-Chem v11-02First and last daily output files missing hourly dataThe run directory update for this fix will be included in the v11-02d tagged version of the GEOS-Chem Unit Tester. File output is incomplete if outputting 1-hr time-averaged data to daily files using filename format %y4%m2%d2.nc in HISTORY.rc. For example, if running GCHP with 1-hr output frequency and 1 day duration for a 1 day simulation the output file should contain 24 time values. The first time should be 30 minutes after the start time, e.g. 00:30:00 if starting the simulation at midnight. However, if HISTORY.rc is configured to show time format string YYYYMMDD in the filename then only one time is in the file and it corresponds to the last of the 24 averaged taken over the day (e.g. 23:30:00). This problem will also appear for other combinations of file duration, frequency, and filename timestamp string. You can avoid this problem by including a finer time unit in the filename. For the case above in which files are output daily, the problem is solved by including hour (%h2) in the filename timestamp string. If outputting files hourly then you should include minutes. In general, always include the time unit smaller than the file frequency time unit. --Lizzie Lundgren (talk) 20:55, 14 December 2017 (UTC) LWI import incorrectly regridded in GCHPThis update will be included in GCHP v11-02d. Prior to v11-02d State_Met%LWI was read in as a met-field import and regridded from lat/lon to cubed sphere in the process. This caused incorrect land/water/ice indexes which are supposed to be 0, 1, or 2 although they are stored as real numbers. Since the source of the LWI met-field is pre-processing using the surface fraction types from GMAO, we now use a similar approach within GCHP to create a 0/1/2 LWI mask from surface type fraction imports. --Lizzie Lundgren (talk) 20:55, 12 December 2017 (UTC) MPICH MPI implementation not readily usable with GCHPThis update will be included in GCHP v11-02d. MPICH is an open-source and widely portable implementation of MPI (MPICH). However, GCHP does not work out-of-the-box with MPICH prior to v11-02d. It instead works with MVAPICH2 which is a derivation of MPICH for use with the Infiniband interconnect. This was a problem for users without Infiniband, such as those using Ethernet interconnect. Using MPICH with GCHP out-of-the-box is possible starting in v11-02d thanks to an update submitted by Sebastian Eastham (MIT). Seb writes:
We recommend that users who do not have access to an Infiniband interconnect use of MPICH over MVAPICH2. --Lizzie Lundgren (talk) 16:49, 6 November 2017 (UTC) MPI_Wait error when running at coarse resolution with high-resolution input dataMAPL crashes when regridding wind vector data from very high resolutions (e.g. 0.25x0.3125 to C24) if running on a small number of cores (e.g. 6). The problem appears to be the production of invalid MPI instructions within the scatter and gather routines. Sebastian Eastham (MIT) determined how to correct the problem if using MVAPICH2 or MPICH: MVAPICH2 When using MVAPICH2, it’s critical that ch3:mrail interface is used. This is the preferred MVAPICH2 interface, but it only works if MVAPICH2 can use the Infiniband connector. Situations where problems will occur include when:
This reflects a flaw in the MVAPICH2 ch3:nemesis interface, which is NOT present in MPICH. To that end… MPICH I have now successfully built and run GCHP using MPICH, and have confirmed that it runs as quickly with MPICH as it does with MVAPICH2 (at least on a single machine and with 6 cores). I have attached a git patch which allows a successful build. Some notes:
--Sebastian D. Eastham (talk) 16 October 2017 (UTC) HEMCO restart variables are not read into ExtDataThis update was included in GEOS-Chem v11-02c. GCHP is not currently compatible with the HEMCO restart file and all HEMCO restart variables are set to /dev/null in ExtData.rc. This is an open issue which will be addressed in v11-02. --Lizzie Lundgren (talk) 21:02, 13 June 2017 (UTC) Some State_Met arrays never set beyond initialization to zeroThis update was included in GCHP v11-02c.</span Meteorology variables EFLUX, U, V, and OMEGA were all zeros in GCHP prior to v11-02c. EFLUX was imported via ExtData.rc but setting State_Met%EFLUX to the import values were omitted in Includes_Before_Run.H. OMEGA, U, and V (orthogonal lat-lon U and V) were not included in Chem_Registry.rc and therefore were not imported. State_Met%OMEGA, State_Met%U, and State_Met%V were initialized in GEOS-Chem but no values other than zero were set. OMEGA is used in sulfate chemistry and EFLUX, U, and V are all used in non-local PBL mixing. Starting in v11-02c, all of these are variables are imported and the associated State_Met arrays are set. Variables U and V are imported as ULL and VLL to distinguish them from imports U and V that are rotated for the cubed-sphere. --Lizzie Lundgren (talk) 16:22, 17 October 2017 (UTC) Day-of-week scale factors not read in by ExtDataThis update was included in GCHP v11-02b and approved on 14 August 2017. Seb Eastham (Harvard) implemented an update in MAPL to allow use of day-of-week scale factors with emissions. He wrote: Data which varies by day-of-the-week can now be read in. Such data must be contained within a single file, and must have exactly 7 or 84 time entries. If 7 entries, these must correspond to each day of the week, starting with Sunday. If 84, this must be 12 7-day sets, one set for each month. Time information will be largely ignored. This read-in mode can be selected by specifying "D" for the "Cyclic" flag in ExtData. --Lizzie Lundgren (talk) 20:26, 12 June 2017 (UTC) GFortran compiler not compatible with GCHPThis update was included in GCHP v11-02b and approved on 14 August 2017. Seb Eastham (Harvard) implemented updates to enable compilation of the high performance option of GEOS-Chem with GFortran. He wrote: Modifications to makefiles required for the build process to recognize, and correctly handle, the use of GCC as the only compiler. This set up was tested with GCC 5.4.0. The code was successfully compiled and run with MVAPICH2, and included the bug fixes in the next few commits: --Lizzie Lundgren (talk) 20:31, 12 June 2017 (UTC) Restart file must contain all advected speciesThis update was included in GCHP v11-02b and approved on 14 August 2017. Lizzie Lundgren (GCST) implemented two updates to allow more flexibility in the use of restart files.
--Lizzie Lundgren (talk) 20:53, 12 June 2017 (UTC) Bug in handling of monthly climatology in DecemberThis update was included in GCHP v11-02b and approved on 14 August 2017. Lizzie Lundgren (GCST) discovered a MAPL bug where the right time bracket is not correctly handled for climatology files during December simulations. This bug does not affect GCHP simulations at other times of the year. Special climatology file handling is needed for edge months of the year (December and January) due to the year change and month number wrap-around. Special handling exists if the current month is January to properly get the climatology for the left bracket (previous) month. Similar handling should occur if the current month is December to properly get the climatology for the right bracket (next) month. Instead, the right bracket special handling is applied only if the current time is January and also improperly sets the right bracket month to December. This results in treating December as any other month for calculation of the right time bracket, thereby iterating the month number by one and subsequently attempting to access data for month 13. The fix is to apply the right bracket special handling if the current month is December and to set variable imm to January. Below is the updated code in GCHP/Shared/MAPL_Base/MAPL_ExtDataGridCompMod.F90 subroutine UpdateBracketTime, with the bug fix shown in red: if (bSide == "R") then
found=.false.
newFile=.true.
status = ESMF_SUCCESS
If (MAPL_Am_I_Root().and.(Ext_Debug > 19)) Write(*,'(a,a,a,I5,x,2L1)') ' DEBUG: Sanity check on file ', trim(file_processed), ' with flags: ', status, status==ESMF_SUCCESS,found
do while ((status==ESMF_SUCCESS).and.(.not.found))
if (trim(cyclic)=='y') then
call ESMF_TimeGet(cTime,yy=iyr,mm=imm,dd=idd,h=ihr,m=imn,s=isc,__RC__)
if (imm == 12) then
cYear = iyr + 1
|
change year you will read from
iyr = climYear-1 call ESMF_TimeSet(readTime,yy=iyr,mm=imm,dd=idd,h=ihr,m=imn,s=isc,__RC__) iyr = climYear |
change month of file
imm = 1
--Lizzie Lundgren (talk) 15:58, 21 June 2017 (UTC) Compile failure if using certain versions of gmakeThis update was included in GCHP v11-02b approved on 14 August 2017. Seb Eastham (Harvard) reported a bug that causes compile failure with certain versions of gmake. There is a typo in Line 72 of GCHP/Shared/GFDL_fms/GNUmakefile where the SUFFIXES command is called as follows: SUFFIXES: += .inc. The SUFFIXES command automatically adds its arguments to the existing list and therefore the extra "+=" is unnecessary and may get misinterpreted or rejected by some versions of gmake. If that happens then gmake will print the following message immediately after starting the GFDL_fms build and then skip the GFDL_fms build entirely: GNUmakefile:72: *** empty variable name. Stop. Note that compilation does not immediately fail and continues until when code needs to use libGFDL_fms.a. As a result, the signature of this error would probably be an error like this: File not found: ….libGFDL_fms.a The solution is to remove the "+/=" from Line 72 of GCHP/Shared/GFDL_fms/GNUmakefile. --Lizzie Lundgren (talk) 18:38, 12 July 2017 (UTC) Simulation crashes if started prior to the first MMDD in climatology filesThis update was included in GCHP v11-02b and approved on 14 August 2017. Prior to GCHP v1.1.0 there was a bug where MAPL subroutine UpdateBracketTime would exit if the current datetime preceded the first datetime of a climatology dataset. This occurred if starting a simulation in January prior to January 15th which is the first date in the monthly XLAI 2008 files used as climatology. The bug resulted in run failure. Seb Eastham (Harvard) corrected this issue by removing the forced exit and replacing it with returning ESMF_FAILURE if both the time precedes the earliest climatology file time and no file is found. For XLAI, a file is found and thus no failure is triggered. Updating bracket time to successfully look for the December file proceeds later in the routine as part of the existing handling of climatology edge months. --Lizzie Lundgren (talk) 20:25, 12 July 2017 (UTC) Rn-Pb-Be7 simulation not functional in GCHP in v1.0.0This update was included in GCHP v11-02b and approved on 14 August 2017. Only the standard simulation is functional in GCHP v1.0.0. The radon simulation will be implemented in v1.1.0 and a corresponding run directory will be available from the GEOS-Chem Unit tester. --Lizzie Lundgren (talk) 21:49, 24 July 2017 (UTC) Outstanding HP issues not yet resolved in GEOS-Chem v11-02Segmentation fault if using volcano emissions with NetCDF 4.2 and higher versions on some systemsSebastian Eastham (MIT) and Jimmie Lin (PKU) have both reported a segmentation fault in GCHP if running a full chemistry simulation with VOLCANO emissions turned on. Both users get the error if using recent NetCDF libraries in which the C and Fortran compilers are split. These libraries are split in all NetCDF versions starting 4.2. However, we have not been able to replicate the problem using a split NetCDF version on the Harvard compute cluster. The error message expected is as follows: forrtl: severe (174): SIGSEGV, segmentation fault occurred Image PC Routine Line Source libintlc.so.5 00002B6B08267961 Unknown Unknown Unknown libintlc.so.5 00002B6B082660B7 Unknown Unknown Unknown libmpi.so.12 00002B6B028154B2 Unknown Unknown Unknown libmpi.so.12 00002B6B02815306 Unknown Unknown Unknown libmpi.so.12 00002B6B02803B5C Unknown Unknown Unknown libmpi.so.12 00002B6B027E54D8 Unknown Unknown Unknown libpthread.so.0 00002B6B084C6330 Unknown Unknown Unknown libnetcdff.so.6 00002B6B02D6FE44 Unknown Unknown Unknown libnetcdff.so.6 00002B6B02DF4BB5 Unknown Unknown Unknown geos 0000000000C7DC7E Unknown Unknown Unknown geos 0000000000C62A8F Unknown Unknown Unknown geos 0000000000A8412A Unknown Unknown Unknown geos 0000000000A7E167 Unknown Unknown Unknown geos 0000000000A71CA8 Unknown Unknown Unknown libesmf.so 00002B6B01A23190 Unknown Unknown Unknown libesmf.so 00002B6B01A232BA Unknown Unknown Unknown libesmf.so 00002B6B01B767B1 Unknown Unknown Unknown libesmf.so 00002B6B01B6F95F Unknown Unknown Unknown libesmf.so 00002B6B01A2486E Unknown Unknown Unknown libesmf.so 00002B6B01C699F5 esmf_compmod_mp_e 991 ESMF_Comp.F90 libesmf.so 00002B6B01E3EA27 esmf_gridcompmod_ 1444 ESMF_GridComp.F90 geos 0000000000A6451B Unknown Unknown Unknown geos 00000000008B264C MAIN__ 38 GEOSChem.F90 geos 000000000040F6FE Unknown Unknown Unknown libc.so.6 00002B6B088F9F45 Unknown Unknown Unknown geos 000000000040F609 Unknown Unknown Unknown It will directly follow a series of warning messages that are triggered by the volcano emissions file: problem in getting akid in NF90_INQ_VARID Until we identify and correct the problem we recommend that users who encounter this error either turn off volcano emissions or try compiling and running with a pre-4.2 version of NetCDF. --Lizzie Lundgren (talk) 17:22, 14 December 2017 (UTC) Resolution dependency of emissionsResolution dependencies within GEOS-Chem prevent users from full utilizing the resolution-independence feature of GCHP. This is particularly an issue for lightning and dust emissions. On this topic, Seb Eastham writes: The existing approach in GEOS-Chem Classic results in inconsistency between simulations at different resolutions. Any emissions extension which included a non-linear function of meteorological data would result in different spatial and temporal emissions distributions over time, depending on the simulation resolution. In the case of lightning emissions, the distribution is constrained in GC Classic by application of redistribution factors, but these factors must be regenerated for each simulation year, resolution, and met product. For both dust and lightning, the total domain emissions mass is further constrained by a single fudge factor, calculated once for each met product, resolution, and subgrid, meaning a new fudge factor is required for every possible nested domain. In the case of other emissions extensions, such as MEGAN and sea salt, no constraint at all is applied, meaning that the emissions are not guaranteed or even likely to be consistent between different resolutions. While this was already becoming a problem in GEOS-Chem Classic, it is untenable in a system like GCHP where one of the unique selling points is flexibility of resolution. --Lizzie Lundgren (talk) 17:57, 9 August 2017 (UTC) Time can only flow forward in MAPLTime must be able to flow backwards in all components of GEOS-Chem in order for the adjoint to be compatible with GCHP. Seb Eastham (Harvard) writes: To run GCHP backwards, I think there are two phases of work that will be needed. --Lizzie Lundgren (talk) 21:12, 13 June 2017 (UTC) Timestep midpoint cos(SZA) is set to cos(SZA) at start of timestepState_Met variables SUNCOS and SUNCOSmid are both set to internal state variable zenith which is extracted at the start of each chemistry timestep in MAPL. This causes out-of-the-box differences with GEOS-Chem "classic" (GCC). This is an open issue which will be addressed in v11-02 as part of our efforts to make GCHP and GCC out-of-the-box standard simulations more comparable. GFortran + MVAPICH2 runs hang if using multiple nodesWhile GCHP successfully compiles with GFortran starting in v1.1.0 (compatible with GEOS-Chem v11-02b), runs hang with an MPI_WAIT error if using cores across multiple nodes. This issue is not guaranteed; it has been observed on the Harvard Odyssey cluster with some builds, but there have also been successful GCHP simulations across multiple nodes when using a different set of GFortran and MVAPICH2 versions. The root cause is not yet known. --Lizzie Lundgren (talk) 21:35, 15 June 2017 (UTC) GCHP is incompatible with GNU compiler v6 due to use of ESMF v5Yanko Davila (University of Colorado) reported the following problem encountered while compiling GCHP with GNU Compiler Collection (GCC) version 6.1.0. He wrote: I’m trying to compile the latest version of GCHP as per the wiki and I’m finding something interesting with gfortran. On file ESMCI_WebServNetEsmfServer.C there is a problem with line 1798 with the equal sign. For some reason gcc version 6.1.0 complains about a wrong function overloading. The following change works for me. @@ -1795,7 +1795,7 @@ void ESMCI_WebServNetEsmfServer::copyFile( fstream fin(srcFilename, ios::in | ios::binary); fstream fout(destFilename, ios::out | ios::binary); - if ((fin == NULL) || (fout == NULL)) + if ((!fin.is_open()) || (!fout.is_open())) Sebastian Eastham (Harvard) explains the fix as follows: The GMAO MAPL infrastructure in GCHP uses ESMF v5, which unfortunately is known to be incompatible with GCC v6 specifically because GCC v6 does not support the if (NULL == file) construct (https://trac.macports.org/ticket/52427). However, ESMF v7 - which GMAO are currently in the process of testing in an unstable branch of MAPL - does support GCC v6. Due to the dependency of GCHP on ESMF v5 at this time and the expected update to ESMF v7 in the near future, we are not applying this fix into the GCHP source code for distribution. However, if you encounter this issue you may modify your local code using this fix. --Lizzie Lundgren (talk) 21:29, 14 July 2017 (UTC) C preprocessor inserting GNU compiler version 6.1.0 information text into MAPL_COMMS___.f90Yanko Davila (University of Colorado) reported that GNU C library license information was inserted in GCHP file MAPL_COMMS____.f90 when using GCC v6.1.0 causing compile failure. Seb Eastham (Harvard) recommended the following fix which is currently being tested. We will incorporate this fix into the standard GCHP source code once it is more thoroughly tested. In GCHP/Shared/Config/ESMA_base.mk, change line 302 (or thereabouts), specifically the CPPANSIX line for gfortran. Change this line of code: CPPANSI="-std=gnu11 -C" to this: CPPANSI="-std=gnu11 -nostdinc -C" --Lizzie Lundgren (talk) 21:43, 14 July 2017 (UTC) |