noresmhub / cam Goto Github PK

What happened?

Changing the number of tasks changed answers in routine testing (e.g., ERP tests). This is usually an indication of a coding bug.

What are the steps to reproduce the bug?

Run any NorESM case which uses Oslo Aero.

What CAM-Nor tag were you using?

cam_cesm2_1_rel_05-Nor_v1.0.5

What machine were you running CAM (or NorESM) on?

Betzy

What compiler were you using?

Intel

Path to a case directory, if applicable

No response

Will you be addressing this bug yourself?

Yes

Extra info

There is an incorrect array reference in a call to calculateNumberConcentration

call calculateNumberConcentration(ncol, aer_cb, rho, CloudnumberConcentration)

should be

call calculateNumberConcentration(ncol, aer_cb(:,:,:,lchnk), rho, CloudnumberConcentration)

What is the feature/what would you like to discuss?

• Specify a new tag for the camnor_phys external which contains the code to implement this change.
• Add namelist variables fv_am_fix_taper, fv_am_fix_taper, and fv_am_fix_taper to control the extended taper.
• Note, this is work from @tto061

Is there anyone in particular you want to be part of this conversation?

No response

Will this change (regression test) answers?

No

Will you be implementing this enhancement yourself?

Yes

Different LUTs are used for calculating the NIR albedo for model r_eff and cosp r_eff:

cosp_optics.F90
USE MOD_MODIS_SIM, ONLY: phaseIsLiquid,phaseIsIce,get_g_nir=>get_g_nir_old,get_ssa_nir=>get_ssa_nir_old

Fixed in CESM2.2

We do not have nudging data to drive CAM-Nor for the latest years. On vilje I found data up to January 2017. Inger-Helene used to prepare those fields. Maybe we should try to prepare nudging fields for more recent years.

What happened?

During code review, several instances of outfld were found where the size of the first dimension of the field inupt (second argument) did not match the size declared in the third argument. This leads to incorrect diagnostic output for all chunks where ncol /= pcols, a situation which occurs on almost every task for the workhorse NorESM experiments.

What are the steps to reproduce the bug?

Read the code

What CAM-Nor tag were you using?

cam_cesm2_1_rel_05-Nor_v1.0.5

What machine were you running CAM (or NorESM) on?

Betzy, Other (please explain below)

What compiler were you using?

Intel, Other (please specify below)

Path to a case directory, if applicable

No response

Will you be addressing this bug yourself?

Yes

Extra info

This problem is independent of platform or compiler.

Trying to collecting the issues here for information.

What is the feature/what would you like to discuss?

Add an option to support explicit volcanic SO2 emissions for the NorESM2.1 release.

Is there anyone in particular you want to be part of this conversation?

No response

Will this change (regression test) answers?

No

Will you be implementing this enhancement yourself?

No

What is the feature/what would you like to discuss?

iHAMMOC: Merge the feature-hamocc-vsls branch into noresm2_3_develop.

• Create (if necessary) compset or user_mods for demonstration case
• Create regression test using the case above
• Create final tag for feature-hamocc-vsls branch
• After merge, rerun regression test to ensure answer preservation
• Create new tag in cam_cesm2_1_rel_05-Nor

Will this change (regression test) answers?

If a regression test is included that tests the features specific to the feature-hamocc-vsls branch, it may change answers for that test.

Will you be implementing this enhancement yourself?

Yes

Issue Type

Code Clean-up

Issue Description

The current implementation of shadow files unfortunately also populated the original non-shadow file code with the #ifdefs of the shadow files. This needs to be undone and all the changes should be solely contained in the shadow files in src_cam in the oslo_aero code base.

Will this change answers?

No

Will you be implementing this yourself?

Yes

What is the feature/what would you like to discuss?

In order to easily keep up with changes in the new CAM physics schemes as well as new aerosol work, bring in changes from cam6_3_112 to the latest tag (currently cam6_3_123).

Is there anyone in particular you want to be part of this conversation?

No response

Will this change (regression test) answers?

Yes

Will you be implementing this enhancement yourself?

Yes

What happened?

In the Externals.cfg in CAM, it attempts to load Externals_CAM.cfg
However, the externals are included as source which causes an attempt to run manage_externals to fail on a standalone CAM checkout.

What are the steps to reproduce the bug?

Clone CAM
Try to run ./manage_externals/checkout_externals.

What CAM-Nor tag were you using?

cam_cesm2_1_rel_05-Nor_v1.0.5

What machine were you running CAM (or NorESM) on?

Other (please explain below)

What compiler were you using?

Other (please specify below)

Path to a case directory, if applicable

No response

Will you be addressing this bug yourself?

Yes

Extra info

Steps to take:

• Remove Externals_CAM.cfg
• Remove CAM entry from Externals.cfg

Currently there is no SST dataset available for 2018 on https://svn-ccsm-inputdata.cgd.ucar.edu/trunk/inputdata/atm/cam/sst/ to drive CAM or CAM-Nor simulations. Might they become available in the near future? Might we get them from somewhere else?
(for 2016 they became available mid-2017, for 2017 in mid-2018. However 2018 and 2019 are still not available).

the wget protocal is not able to download the content of the AeroTab folder. we have to name the file names to provide a list of the files (56 files) to be downloaded. we suggest to group the various files in accordance to: aerocomk, aerodryk, kcomp, logntil, lwkcomp - which requires some knowledge of the code

We also need to be clear on which files are used by the model. All files are copied, but not necessarily used which is a waste of resources.

What is the feature/what would you like to discuss?

As part of the development of the next version of NorESM, re-implement the Oslo-aero aerosol scheme using the new aerosol object types.aerosol_properties and aerosol_state.

Is there anyone in particular you want to be part of this conversation?

@ingvi

Will this change (regression test) answers?

Yes

Will you be implementing this enhancement yourself?

No

Issue Type

Other (please describe below)

Issue Description

This PR adds new wind fields that WW3DEV should get (instead of ubot and vbot that it is getting now that are not at 10m but rather closer to 60m).

Will this change answers?

No

Will you be implementing this yourself?

Yes

What is the feature/what would you like to discuss?

Add a new chemistry scheme which includes Bromoform for the NorESM2.3 release.

Is there anyone in particular you want to be part of this conversation?

No response

Will this change (regression test) answers?

No

Will you be implementing this enhancement yourself?

No

What is the feature/what would you like to discuss?

Add the SpAero (specified aerosol) chemistry scheme to the NorESM2.3 release.

Is there anyone in particular you want to be part of this conversation?

No response

Will this change (regression test) answers?

No

Will you be implementing this enhancement yourself?

No

NF2000climo is a useful compset for development but since it was not used for CMIP6 the settings have not been updated. I have started this issue to report on improving this compset

Due to the high dry deposition of coarse mode particles in NorESM, there is an additional parameterisation combining dry deposition and emissions in one equation. This was done to reduce the sea-saw pattern in concentrations that can be found when large emissions is followed by large deposition. This sea-saw pattern was likely exaggerated by the error in dry deposition which is now corrected
The parameterisation can be found in oslo_aerosols_intr.F90

Describe the solution you would like to see
We should consider removing the addtional parameterisation at least for a sensitivity test to check how important it is for the budget and for understanding differences compared to standard CAM

Issue Type

Other (please describe below)

Issue Description

I tried to run ModivsModII on runs with startyear= 1985, and noticed that the filelist created by create-clim.sh only contained files with 1985. The script rewrites and updates the year-variable that goes into the creation of filelist entries (variable: aaYear) only if "FIRSTYEAR" is lower than 1000. For "FIRSTYEAR" > 1000, the variable 'aaYear', which is initially set to "FIRSTYEAR", stays unchanged. This can be easily fixed by updating the variable 'aaYear' with the while-loop counter-variable 'aYear' at the beginning of the loop.

Will this change answers?

No

Will you be implementing this yourself?

No

What happened?

There is an artificial limit on the number of ice particles.

What are the steps to reproduce the bug?

Run the standard NorESM2 code.

What CAM-Nor tag were you using?

cam_cesm2_1_rel_05-Nor_v1.0.5

What machine were you running CAM (or NorESM) on?

Betzy

What compiler were you using?

Intel

Path to a case directory, if applicable

No response

Will you be addressing this bug yourself?

No

Extra info

The subroutine micro_mg_tend in the file src/NorESM/micro_mg2_0.F90 has to be changed :

The lines

!  if (do_cldice .and. nitend(i,k).gt.0._r8.and.ni(i,k)+nitend(i,k)*deltat.gt.nimax(i,k)) then
!    nitncons(i,k) = nitncons(i,k) + nitend(i,k)-max(0._r8,(nimax(i,k)-ni(i,k))/deltat) !AL
!     nitend(i,k)=max(0._r8,(nimax(i,k)-ni(i,k))/deltat)
!  end if

should be replaced by

!shofer---
! OS Also added the term from secondary ice formation (but we don't need that now)
if (nnucct(i,k)+nnuccc(i,k)+nnudep(i,k).gt.0._r8) then
!		nimax(i,k) = nimax(i,k)+(nnucct(i,k)+nnuccc(i,k)+nnudep(i,k)+SIP_RATE(i,k))*lcldm(i,k)*deltat	
		nimax(i,k) = nimax(i,k)+(nnucct(i,k)+nnuccc(i,k)+nnudep(i,k))*lcldm(i,k)*delta
end if

if (do_cldice.and.nitend(i,k).gt.0._r8.and.ni(i,k)+nitend(i,k)*deltat.gt.nimax(i,k)) then
		nitncons(i,k) = nitncons(i,k) + nitend(i,k)-max(0._r8,(nimax(i,k)-ni(i,k))/deltat)
		nitend(i,k)=max(0._r8,(nimax(i,k)-ni(i,k))/deltat)
end if
!shofer---

What is the feature/what would you like to discuss?

Add a new chemistry scheme that covers both the troposphere and stratosphere for the NorESM2.3 release.
Note, this scheme will include both bromoform and explicit volcanic emissions.

Will this change (regression test) answers?

A new regression test will be introduced

Will you be implementing this enhancement yourself?

No

Issue Type

Code Clean-up

Issue Description

The file, preprocessorDefinitions.h, in CMIP6 use cases for NorESM should be removed and replaced with xmlchange commands.

Will this change answers?

No

Will you be implementing this yourself?

No

Hi all,
I cannot seem to find any reference for why the SOA yield for isoprene is 5%, anyone who knows? The 15 % for monoterpene seems to be from Dentener et al (2006) which seems to have gotten it possibly from Kanakidou et al 2005 who say something like "let us assume that 15% ... )

More worrying from my side is that in the model, as far as I can tell, we use molar yields and not mass yields, while the litterature tends to present mass yields. E.g. for isoprene (which is much smaller than the assumed SOA_SV), the molar yield is set to 5 %, but that amounts to a mass yield of almost 12% if I am not mistaken. This is rather on the high end of what the litterature suggests. For monoterpenes, the difference is less because it is only assumed to gain 2 oxygen, which is percentwise only a 20% increase.

What is the feature/what would you like to discuss?

For now the proposed way is to primarily add CPP-ifdefs that would enable the testing for a major refactorization later on to keep bit-for-bit.

Is there anyone in particular you want to be part of this conversation?

@ingvisau @gold

Will this change (regression test) answers?

No

Will you be implementing this enhancement yourself?

Yes

The README file in the main branch is missing descriptions for two NorESM/CAM tags; cam_cesm2_1_rel_05-Nor_v1.0.3 and cam_cesm2_1_rel_05-Nor_v1.0.4.

Suggested for descriptions

• cam_cesm2_1_rel_05-Nor_v1.0.3: New use cases and a microphysics bug fix
• cam_cesm2_1_rel_05-Nor_v1.0.4: Improved configuration for production tagged aerosols

What happened?

GitHub removed support for their svn 'bridge' which allowed using the svn protocol with GitHub repositories. This was used to reduce the size of the clones and working trees for COSP and CLUBB.
CAM tags or hashes with svn protocol use in the externals will fail in checkout_externals.

What are the steps to reproduce the bug?

Try running ./manage_externals/checkout_externals on a CAM checkout with svn protocol use in Externals_CAM.cfg

What CAM-Nor tag were you using?

noresm_v8_cam6_3_123

What machine were you running CAM (or NorESM) on?

Other (please explain below)

What compiler were you using?

Other (please specify below)

Path to a case directory, if applicable

No response

Will you be addressing this bug yourself?

Yes

Extra info

Fix this by using git sparse checkout.

Issue Description

The ice delimiter bug correction implemented in response to #110 leaves the model in an unbalanced state that requires tuning to fix. For the NorESM2.1 release, we will leave this correction in the code but include a compile-time option to revert this change so that the results are more in line with the NorESM2.0 release.

Will this change answers?

Yes

Will you be implementing this yourself?

Yes

Issue Type

Other (please describe below)

Issue Description

I have tried to run cam-diagnostics on the simulation found at Betzy: /cluster/work/users/mvertens/archive/NB1850proto01
The simulations are with SE dycore with output regridded to FV 0.9x1.25 degree grid

The diagnostics simulation fails with the error message:(0) unstructured_to_ESMF: latitude and longitude must have the same number of elements: /cluster/work/users/oyvinds/diagnostics/out/CAM_DIAG/config/NB1850proto01/logs/out_240208_153621.log
Prior to the fail, the averaged files are given an SE name e.g /cluster/work/users/oyvinds/diagnostics/out/CAM_DIAG/climo/NB1850proto01/sav_se/NB1850proto01_01_000201_001101_climo_SE.nc
Another possible point of failure is that the variable name used for latitude weights are w, not gw as used to be the standard in FV.

Possible test: A SE simulation of 14 months or more to see if the diagnostics tool can manage SE grid output.

Will this change answers?

No

Will you be implementing this yourself?

No

What happened?

Error in the calculation of the dry deposition.

What are the steps to reproduce the bug?

Run standard NorESM2

What CAM-Nor tag were you using?

cam_cesm2_1_rel_05-Nor_v1.0.5

What machine were you running CAM (or NorESM) on?

Betzy

What compiler were you using?

Intel

Path to a case directory, if applicable

No response

Will you be addressing this bug yourself?

No

Extra info

The subroutine oslo_aero_dry_intr in the file src/chemistry/oslo_aero/oslo_aerosols_intr.F90 should be modified.

The corrected code should look like (old code commented out) :

       rad_aer(1:ncol,top_lev:) = 0.5_r8*dgncur_awet(1:ncol,top_lev:,m)  
!                         *exp(1.5_r8*(logSigma))
	                   *exp(1.5_r8*(logSigma**2))
		...
        rad_aer(1:ncol,top_lev:) = 0.5_r8*dgncur_awet_processmode(1:ncol,top_lev:,processModeMap(mm))
!	                     *exp(1.5_r8*(logSigma))
                            *exp(1.5_r8*(logSigma**2))

Issue Type

Other (please describe below)

Issue Description

This will permit easier comparison of oslo-aero with tropmam4

Will this change answers?

Yes

Will you be implementing this yourself?

Yes

The look-up tables which are supposed to be in AeroTab_8jun17 are not automatically downloaded for all the compsets where they are needed (like NF2000climo, etc.) but only for those whose longname contains "_CAM60%NORESM"

What happened?

The following test fails - whereas the following test passes using noresm2_3_develop
EM_Ln9.f09_f09_mtn14.NF1850norbc.betzy_intel.cam-outfrq9s

What are the steps to reproduce the bug?

Run the test on betzy using noresm2_5_alpha01 tag (note this is not a cam tag - but a noresm tag - which contains cam tag noresm_v8_cam6_3_123.

What CAM-Nor tag were you using?

noresm_v8_cam6_3_123

What machine were you running CAM (or NorESM) on?

Betzy

What compiler were you using?

Intel

Path to a case directory, if applicable

No response

Will you be addressing this bug yourself?

Yes

Extra info

No response

What is the feature/what would you like to discuss?

As part of building the new CAM-Nor version, pp_trop_mam_oslo needs to be restored or re-implemented from the noresm2 version.

Given that the chemistry pre-processor has changed, it will probably be necessary to regenerate the source code using the new pre-processor version. This will be done unless a test shows no source-code change.

There is not a lot of history of pp_trop_mam_oslo in this repository, however, the relevant comments in the log record will be copied into the log for this work.

Is there anyone in particular you want to be part of this conversation?

No response

Will this change (regression test) answers?

Yes

Will you be implementing this enhancement yourself?

Yes

I was looking at my runs with the latest release (release-noresm2.0.1) and I noticed that the CCN values seem to be very weird. Basically they seem to have the same pattern at all supersaturations (see plots) ( (CCNx/CCNy) is constant everywhere.)

(same pattern is true of all CCNx)

I emailed with @oyvindseland (cc @Kirkevag @DirkOlivie) about this and @oyvindseland confirmed this in his results (so it's probably not that I messed up my version).

Does anyone have an idea what might have caused this? Are there any plans to look into it?

The implementation of the SpAer code used in CMIP6 (e.g. for piClim-SpAer2014) has been put on hold to make sure that other CMIP6 simulations not could be affected by possible bugs in this code-wise quite big task.

In pmxsub.F90.

Two variables (vnbcarr and vaitbcarr), now initialized with Alok's bugfixes, are calculated, but before they are used for the first time. This is therefore a bug: the effect of this bug concerns extra diagnostics of optics at RH=0% only (for the INSITU AeroCom optics experiment): mixture 4 and 14 does not have the right volume fraction of BC for this particular RH. The loop over higher RH values are done after calculating vnbcarr and vaitbcarr, so that part seems to be OK. This should not affect any other things (meteorology etc) than just this particular set of diagnostics for assumed RH=0%.

Issue Type

Documentation Update

Issue Description

Remove <science_support> tags from config_compsets.xml

Will this change answers?

No

Will you be implementing this yourself?

Yes

What is the feature/what would you like to discuss?

New tests needed for the noresm2.1 release are the following:

"Stand-alone CAM" (F compsets):
3 compsets, 2 resolutions

• platform betzy for all, fram for just f19_f19
• Test resolutions: f19_f19, f09_f09 (NOTE: the mask is set to gx1v6 - but the domain files use mtn14)
• Test types ERP, SMS_D,PFS
• NF1850norbc for f19_f19, NF1850frc2norbc for f09_f09 (N1850 model SST + forcing from 1850)
• NF1850norbc_aer2014 for f19_f19, NF1850frc2norbc_aer2014 for f09_f09 (N1850 model SST + forcing from 1850, except aerosols from 2014 emissions)
• NFHISTnorpddmsbc for f09_f09

Is there anyone in particular you want to be part of this conversation?

@gold2718

Will this change (regression test) answers?

There are no regressions tests yet - so this will introduce regression testing.

Will you be implementing this enhancement yourself?

Yes

Issue Type

Infrastructure Update

Issue Description

Some CAM externals (e.g., CLUBB) are currently cloned by using the svn protocol and its ability to checkout (clone) only a section of a repository. However, Microsoft is "sunsetting" this feature (the GitHub-svn bridge) so a new method must be used.
Currently, GitHub is "warning" everyone about the upcoming change by creating "brownouts" of the svn bridge so it currently works sometimes. This should be updated in the noresm_develop branch ASAP.

Will this change answers?

No

Will you be implementing this yourself?

Yes

Hi all!
I had a quick look at the SOA_NAclcoagTend from a run I did and the other clcoagTend outputs and they look like they have some kind of numerical issue, possibly on top of the real values.
I also checked the aerocom runs that @Kirkevag did and it seems to have the same issues.
/projects/NS2345K/noresm/cases/NFHISTnorpddmsbcsdyn_f09_mg17_20191101

Issue Type

Code Clean-up

Issue Description

There are many print statements that print common information to the log from every task. Unless a task is reporting an error condition, these should be limited to writes to iulog from a single task.

Will this change answers?

No

Will you be implementing this yourself?

Yes

Add templates for new issues and for pull requests.
Users often do not enter enough information in an issue to allow for discussion or bug fixing.
These templates help prompt the user to enter all necessary and helpful information.

There are currently a lot of tags from CAM obscuring the view to the NorESM specific tag. Can one remove the less important tags possibly from the NorESM2 branch, or make a certain tag be the default view when enetering the CAM repo?

@NorESMhub/camnor-core

Problem: The README.md file on the CAM main branch is quite out of date and somewhat inaccurate.
Solution: Fix it.

What is the feature/what would you like to discuss?

Bring in the FORCeS experiment
In addition to the coupled compsets (see NorESMhub/NorESM#465), implement these AMIP compsets:

• NF1850FORCeS: FORCeS tunings
• NFHISTFORCeS: FORCeS tunings
• NF1850norbcForces: FORCeS tunings
• NFHISTnorbc_aer2014Forces: FORCeS tunings
• NF1850: KeyClim 1850 Cloud2
• NFHIST: KeyClim 1850 Cloud2

Details of code differences are in #108

Will this change (regression test) answers?

Yes

Will you be implementing this enhancement yourself?

Yes

Discussed in #104

What is the feature/what would you like to discuss?

Implement a more an explicit (sectional nucleation sizes) aerosol nucleation as chemistry option for the NorESM2.3 release.

Is there anyone in particular you want to be part of this conversation?

No response

Will this change (regression test) answers?

No

Will you be implementing this enhancement yourself?

No

Issue Type

Code Clean-up, Infrastructure Update

Issue Description

Some of the code used for experiments is still on SourceMods under the experiment and should be pushed to the branch
Changes in namelist should be defined as a user mod?
After disucssion: Should the code changes be included in the main NorESM / or NorESM-KeyClim branch as a namelist option or should it stay at a private fork?

The modified code changes the climate of the model when turned on.
The modified code is bit-identical if the modifications are turned off.

Will this change answers?

Yes

Will you be implementing this yourself?

Yes