BGC included 1deg_jra55_iaf #11

hakaseh · 2021-05-03T01:04:59Z

Hello @aekiss @aidanheerdegen @AndyHoggANU @russfiedler and maybe others,

I was not sure if creating pull request was the way to go, but I would like to let you know that I have updated 1deg_jra55_iaf with BGC. This should work with the recently developed BGC implementaiton: mom-ocean/MOM5#338 and COSIMA/cice5#58

To exchange two BGC tracers between ice and ocean, i2o.nc, o2i.nc, namcouple, ocean/input.nml, and ice/input_ice.nml were updated. The BGC input files are currently stored in /g/data/v45/hh0162/projects/icebgc/prep_omip2/iamip2

The default setup will run the model with physics only. To run the model with BGC, do:

cat ocean/field_table_bgc >> ocean/field_table
cat ocean/diag_table_bgc >> ocean/diag_table

The default BGC setup will include both ocean and sea-ice BGC. To turn off the sea-ice BGC, set skl_bgc = .false. in ice/cice_input.nml.

Therefore, running the BGC model requires additional steps, but I think this is better than creating and maintaining two separate directories for physics-only and bgc-included experiments.

Any thoughts? Could you do test runs and if they are successful and you are happy with the way the directory is setup, I'll prepare for 0.25 and 0.1-degree (as well as RYF).

aekiss · 2021-05-06T01:22:59Z

Great, thanks @hakaseh.

I can give it a whirl but it looks like /g/data/v45/hh0162/projects/icebgc/prep_omip2/input_iamip2/co2_obs_iamip2_con.nc is a broken link - can you fix that please?

Once we are happy with it I'll

move those extra inputs to /g/data/ik11/inputs/access-om2
set up the diagnostics using diag_table_source.yaml
make the same changes to 1deg_jra55_ryf

hakaseh · 2021-05-10T02:42:47Z

Sounds good, thanks Andrew. I realised I should change some of the input files, so I will create a new input directory for these experiments and will reply to this thread when it is ready. From: Andrew Kiss ***@***.***> Date: Thursday, 6 May 2021 at 11:23 am To: COSIMA/1deg_jra55_iaf ***@***.***> Cc: Hakase Hayashida ***@***.***>, Mention ***@***.***> Subject: Re: [COSIMA/1deg_jra55_iaf] BGC included 1deg_jra55_iaf (#11) Great, thanks @hakaseh<https://github.com/hakaseh>. I can give it a whirl but it looks like /g/data/v45/hh0162/projects/icebgc/prep_omip2/input_iamip2/co2_obs_iamip2_con.nc is a broken link - can you fix that please? Once we are happy with it I'll * move those extra inputs to /g/data/ik11/inputs/access-om2 * set up the diagnostics using diag_table_source.yaml * make the same changes to 1deg_jra55_ryf — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#11 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AMDA5P42M2HQSJSPBZ2NGGLTMHVQFANCNFSM4376U7ZQ>.

hakaseh · 2021-05-11T01:41:41Z

Hi @aekiss. I created a new input directory for BGC runs. It is ready for testing.

aekiss · 2021-05-11T03:58:19Z

Thanks @hakaseh.

Your PR's config.yaml uses fms_ACCESS-OM-BGC_09931a0_libaccessom2_44e8821-modified.x and cice_auscom_360x300_24p_30ba0cc-modified_libaccessom2_44e8821-modified.exe so it was built with locally-modified libaccessom2 source files newer than 44e8821.
Can you commit those modifications and make a PR for them at https://github.com/COSIMA/libaccessom2?

You'll have to do some thing similar for CICE - see here.

When you've committed your changes to CICE and libaccessom2 you should re-run install.sh to make fresh executables, and use these new exe filenames in config.yaml for ocean, ice and atmosphere (the 3 filenames should all end with the same hash, and none of them should contain "modified") and then push them to this PR.

aekiss · 2021-05-11T04:02:53Z

Also there are permissions problems so I can't run your executables:

$ ls /home/581/hh0162/scratch/access-om2-iamip2/bin/fms_ACCESS-OM-BGC_09931a0_libaccessom2_44e8821-modified.x
ls: cannot access '/home/581/hh0162/scratch/access-om2-iamip2/bin/fms_ACCESS-OM-BGC_09931a0_libaccessom2_44e8821-modified.x': Permission denied
$ ls /home/581/hh0162/scratch/access-om2-iamip2/bin/cice_auscom_360x300_24p_30ba0cc-modified_libaccessom2_44e8821-modified.exe
ls: cannot access '/home/581/hh0162/scratch/access-om2-iamip2/bin/cice_auscom_360x300_24p_30ba0cc-modified_libaccessom2_44e8821-modified.exe': Permission denied

hakaseh · 2021-05-11T04:05:29Z

not sure if I understood correctly, but i should update the executables specified in config.yaml, correct?

i noticed in the past that executables in config.yaml get updated automatically for some directories but not in other directories. do you know how it determines which config.yaml to modify automatically upon successful ./install.sh?

aekiss · 2021-05-11T04:13:45Z

The automatic updating of exes in config.yaml is done by hashexe.sh but it's a bit buggy and doesn't always work, so you may need to do it by hand.
But before doing that, you should commit and push any uncommitted changes you made in cice and libaccessom2.

hakaseh · 2021-05-11T04:24:12Z

i see. The default directories (e.g. 1deg_jra55_iaf) are defined in hashexe.sh, so anything else i added (e.g. 1deg_jra55_iaf_iamip2_his) was not automatically updated. ok, i will do manually.

i think i now understand what you mean by updating the executables. i can confirm that my latest CICE commit is:

commit 30ba0cc90a1c0ed552a267dca03f8e68e7cf312e (HEAD -> iamip2, hakaseh/iamip2)
Author: hakase hayashida hakase.hayashida@utas.edu.au
Date: Wed Mar 24 14:44:35 2021 +1100

fix typo.

I only had to update MOM to fix the errors raised during PR.
I did not modify anything in libaccessom2.

I just did "chmod 744 /home/581/hh0162/scratch/access-om2-iamip2/bin/". could you access now?

aekiss · 2021-05-11T04:30:46Z

What cice executable name do you get when you run install.sh?
cice_auscom_360x300_24p_30ba0cc-modified_libaccessom2_44e8821-modified.exe indicates that both cice and libaccessom2 have modifications that have not been committed.

I can't access /home/581/hh0162/ so you'll need to relax permissions for the parent directories too.

hakaseh · 2021-05-11T04:35:28Z

Oh I see. sorry i do have uncommitted changes in CICE, but that is not for this release of OM2-BGC. I've been testing different options for CICE like brine tracers.

I modified the permissions again, hopefully this time works?

aekiss · 2021-05-11T04:59:50Z

We want to keep track of exactly what source code is used in the executables, so you should commit all your changes before you run install.sh.
If you have unrelated changes in cice, maybe you should start a new branch for them and commit them there, then do git checkout iamp2 and re-run install.sh.
Can you also cd src/libaccessom2; git diff to see what's been changed there?

Also, can you tell me where your source code is? It might be easier if I look at it myself.

I can now get into /home/581/hh0162/ but not /home/581/hh0162/scratch - what does this link to? I guess it's a project i'm not a member of.

hakaseh · 2021-05-11T13:44:06Z

I guess the unrelated change in CICE is minimal, so instead of creating a new branch, I updated the iamip2 branch for cice now:

COSIMA/cice5@f488bde

I have a question before doing ./install.sh and updating executables. When I do git status, I still get one modified and unstaged directory:

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
  (commit or discard the untracked or modified content in submodules)
	modified:   ParallelIO (modified content)

where the difference/modification is:

(base) [hh0162@gadi-login-02 cice5]$ git diff ParallelIO
diff --git a/ParallelIO b/ParallelIO
--- a/ParallelIO
+++ b/ParallelIO
@@ -1 +1 @@
-Subproject commit 7309b9b60868357e519eff5aa22e36fc51d94eed
+Subproject commit 7309b9b60868357e519eff5aa22e36fc51d94eed-dirty

Do I need to commit this as well?
Actually, all the changes in libaccessom2 are similar:

(base) [hh0162@gadi-login-02 libaccessom2]$ git diff
diff --git a/datetime-fortran b/datetime-fortran
--- a/datetime-fortran
+++ b/datetime-fortran
@@ -1 +1 @@
-Subproject commit f5310d92bb41f36909d665bbc19869169b2276ac
+Subproject commit f5310d92bb41f36909d665bbc19869169b2276ac-dirty
diff --git a/json-fortran b/json-fortran
--- a/json-fortran
+++ b/json-fortran
@@ -1 +1 @@
-Subproject commit 690a8bd2353fe8256448e6321d462b70e3e9daf8
+Subproject commit 690a8bd2353fe8256448e6321d462b70e3e9daf8-dirty
diff --git a/oasis3-mct b/oasis3-mct
--- a/oasis3-mct
+++ b/oasis3-mct
@@ -1 +1 @@
-Subproject commit 3872880303f8957f716d8ca943d3bfef0fee1c95
+Subproject commit 3872880303f8957f716d8ca943d3bfef0fee1c95-dirty

I don't understand what these mean, but found this thread:

https://stackoverflow.com/a/4874323

should I follow?

hakaseh · 2021-05-11T13:52:34Z

regarding permission issue, my scratch is v45, but the group was set to v19. not sure how this happened, but i just did chgrp -R now.

hakaseh · 2021-05-12T00:54:44Z

I did "./install.sh" and it still produces *-modified.exe for CICE, e.g.:

exe: /home/581/hh0162/scratch/access-om2-iamip2/bin/cice_auscom_360x300_24p_30ba0cc-modified_libaccessom2_44e8821-modified.exe

so i think that *-dirty commit needs to be sorted?

aekiss · 2021-05-12T01:36:49Z

Hmm, it looks like your submodule links are old, e.g. ParallelIO 7309b9b6 is older than 7e242f7 which is what we currently use: https://github.com/COSIMA/cice5

Maybe try this and see it updates ParallelIO to 7e242f7

cd src/cice
git submodule update --init --recursive

It's less clear what's wrong with libacessom2 submodules, as the hashes match those in https://github.com/COSIMA/libaccessom2/tree/44e8821ee
but you could try

cd ../libaccessom2
git submodule update --init --recursive

and see what it does... @aidanheerdegen do you have any better suggestions?

It would be good if I could see your code directory but I still have no access to /home/581/hh0162/scratch...

hakaseh · 2021-05-12T03:23:49Z

I don't know if I have ever updated other modules/directories than src/mom and src/cice, so maybe that's why.. I'll try your method.

I'm currently doing chmod -R 754 /scratch/v45/hh0162. Compared to other members of v45, I noticed mine had slightly different permission with a capital letter S for group permission:

drwxr-Sr-- 8 hh0162 v45 16384 Mar 4 09:44 hh0162

Do you think it would be easier if you pull my src/cice and src/mom and do ./install.sh and do a test run with my modified 1deg_jra55_iaf? You just need to replace the executables with your compiled ones in config.yaml.

aidanheerdegen · 2021-05-12T03:48:20Z

Recursively changing the permissions has created a lot of modified files in your source directory as you've made everything executable.

Not sure this is heading in the right direction ...

hakaseh · 2021-05-12T04:11:14Z

I had this issue before and managed to avoid it for src/cice and src/mom by following this:
https://stackoverflow.com/a/1580644
But I am not sure if this works for other places in the source code...

aekiss · 2021-05-12T07:03:35Z

OK I'll try compiling them myself.

But first - your cice5 iamip2 branch has slipped behind the current master in cice5 - see
https://github.com/hakaseh/cice5/tree/iamip2

so can you go to your cice5 source directory and do

git checkout iamip2
git merge master
git submodule update --init --recursive

and then push it to your iamip2 branch on github?

hakaseh · 2021-05-13T23:32:10Z

thanks @aekiss that'd be great.

I have followed the steps to update the iamip2 branch of cice5.

aekiss · 2021-05-20T06:01:26Z

hi @hakaseh - just to update: so far I've merged your changes with the latest model components (in a private branch which I will share later), compiled and run successfully in physics-only.

(edited)

I noticed your field_table_bgc is very different from field_table, even for the non-BGC, e.g. using a different advection scheme. Is there a reason for this? It would be better if the changes are as minimal as possible.

I noticed your field_table_bgc uses different advection schemes from field_table, i.e. mdfl_sweby or upwind instead of mdppm.

Is there a reason for this? If not, can we switch them all to mdppm?

aekiss · 2021-05-20T07:04:49Z

My BGC run is failing with

FATAL from PE     1: fms_io(restore_state_one_field): Checksum of input field CACO3               0 does not match value E1128609DB6D35F4stored in CSIRO_BGC.RES.NC.

aekiss · 2021-10-14T22:10:34Z

thanks @hakase, I've merged my branch so you can pull main

hakaseh · 2021-10-15T01:44:41Z

@aekiss
I just pushed the updates to a new branch hh-dev.

aekiss · 2021-10-15T04:34:08Z

thanks @hakaseh, I've merged that into main. Does this mean we can delete
/g/data/v45/hh0162/projects/icebgc/prep_omip2/input_om2-bgc/*deg*/ocean_grid_xyz.nc
?
ie access-om2 doesn't use them?

hakaseh · 2021-10-15T04:42:54Z

Yup, we can delete them. Not used in simulations. Regards, Hakase

…

________________________________ From: Andrew Kiss ***@***.***> Sent: Friday, October 15, 2021 3:34:20 PM To: COSIMA/1deg_jra55_iaf ***@***.***> Cc: Hakase Hayashida ***@***.***>; Mention ***@***.***> Subject: Re: [COSIMA/1deg_jra55_iaf] BGC included 1deg_jra55_iaf (#11) thanks @hakaseh<https://github.com/hakaseh>, I've merged that into main. Does this mean we can delete /g/data/v45/hh0162/projects/icebgc/prep_omip2/input_om2-bgc/*deg*/ocean_grid_xyz.nc ? ie access-om2 doesn't use them? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#11 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AMDA5PYGC5MXIIBKWEDTNOLUG6VMZANCNFSM4376U7ZQ>.

aekiss · 2021-10-15T07:06:57Z

@hakaseh I've just been looking through /g/data/v45/hh0162/projects/icebgc/prep_omip2/input_om2-bgc/*deg* and noticed a few things to double-check with you next week, which I'll put here so I don't forget.

aekiss · 2021-10-15T07:16:49Z

/g/data/v45/hh0162/projects/icebgc/prep_omip2/input_om2-bgc/*deg*/csiro_bgc.res.nc
initializes constant phy=0.01,zoo=0.01 at all depths, which seems odd to me and is very different from BRAN (Oke et al 2013) and ACCESS-ESM1 (Law et al 2017) which initialize phy in the top 100m based on SeaWifs obs scaled to phosphorus units, and initialize zoo=0.05phy. Presumably both are zero below 100m.
If you want to follow that approach, we have chlorophyll files (of uncertain origin) here that might be suitable: /g/data/ik11/inputs/access-om2/input_20201102/mom_*deg/chl.nc. @russfiedler might know more about their provenance.

aekiss · 2021-10-15T07:18:50Z

/g/data/v45/hh0162/projects/icebgc/prep_omip2/input_om2-bgc/*deg*/csiro_bgc.res.nc
also initialize constant caco3=0.01,det=0.01 at all depths. Are these values and depth distributions reasonable?
Oke et al 2013 and Law et al 2017 don't explain how they initialize these.

aekiss · 2021-10-15T07:49:37Z

/g/data/v45/hh0162/projects/icebgc/prep_omip2/input_om2-bgc/*deg*/i2o.nc
initialise nit_io=0.1 and alg_io=0.1, but
/g/data/v45/hh0162/projects/icebgc/prep_omip2/input_om2-bgc/*deg*/o2i.nc
initialise ssn_i=1 and ssalg_i =1

Are these values OK? It seems odd that nutrient and algae would have the same values.

Should ssn_i be derived from no3 in /g/data/v45/hh0162/projects/icebgc/prep_omip2/input_om2-bgc/*deg*/csiro_bgc.res.nc? This varies over several orders of magnitude, so a constant 1 seems odd.
Should ssalg_i be derived from phy in /g/data/v45/hh0162/projects/icebgc/prep_omip2/input_om2-bgc/*deg*/csiro_bgc.res.nc? This is currently 0.01 but may itself need changing.

aekiss · 2021-10-15T08:05:09Z

/g/data/v45/hh0162/projects/icebgc/prep_omip2/input_om2-bgc/*deg*/i2o.nc
initialise wnd10_io to a constant (0.1 for 1deg and 0.25deg, but 0 for 0.1deg and 0.1deg-cycle4; not sure why they differ).
This seems inconsistent with the other wind-related fields in the same file (strsu_io, strsv_io), which are spatially variable.
Would something from JRA55-do be better?

aekiss · 2021-10-15T08:08:18Z

/g/data/v45/hh0162/projects/icebgc/prep_omip2/input_om2-bgc/025deg/i2o.nc
most fields have 1e30 values in missing tiles.
This seems to have been inherited from /g/data/ik11/inputs/access-om2/input_20201102/025deg/i2o.nc, which works fine, so I guess we can leave it.

aekiss · 2021-10-15T08:26:00Z

valid_range, longname, standard_name and units attributes are wrong and should be deleted from

/g/data/v45/hh0162/projects/icebgc/prep_omip2/input_om2-bgc/1deg/csiro_bgc.res.nc
/g/data/v45/hh0162/projects/icebgc/prep_omip2/input_om2-bgc/01deg/csiro_bgc.res.nc
/g/data/v45/hh0162/projects/icebgc/prep_omip2/input_om2-bgc/01deg-cycle4/csiro_bgc.res.nc

these attributes are already absent from
/g/data/v45/hh0162/projects/icebgc/prep_omip2/input_om2-bgc/025deg/csiro_bgc.res.nc

aekiss · 2021-10-15T08:41:50Z

Ideally we'd make changes in https://github.com/COSIMA/input_om2-bgc and re-generate the files, so we can document the provenance of each file by a global attribute with a link to the specific input_om2-bgc commit, using a script like this https://github.com/COSIMA/initial_conditions_access-om2/blob/master/finalise.sh

aekiss · 2021-10-15T08:42:39Z

Anyway, it's the weekend so let's discuss next week.

hakaseh · 2021-10-18T04:55:28Z

many thanks @aekiss for these checks. I'm going through your posts and try to address them all below. I'm busy with the CLEX OE workshop tomorrow until Wednesday, and it's the long weekend in Tasmania from Thursday until Sunday, so I might not get to these again until next week.

/g/data/v45/hh0162/projects/icebgc/prep_omip2/input_om2-bgc/*deg*/csiro_bgc.res.nc initializes constant phy=0.01,zoo=0.01 at all depths, which seems odd to me and is very different from BRAN (Oke et al 2013) and ACCESS-ESM1 (Law et al 2017) which initialize phy in the top 100m based on SeaWifs obs scaled to phosphorus units, and initialize zoo=0.05phy. Presumably both are zero below 100m. If you want to follow that approach, we have chlorophyll files (of uncertain origin) here that might be suitable: /g/data/ik11/inputs/access-om2/input_20201102/mom_*deg/chl.nc. @russfiedler might know more about their provenance.

The initial conditions for these BGC tracers are somewhat arbitrary, unless they are used for short-term forecasting (initial value problem). I set all of these to 0.01 mmol/m3, which is a very small value, for simplicity. This is a common approach in BGC models, given the lack of climatology in these fields, and we know that these values are for the most part minimal, except in the upper 100 m (phy and zoo) and at times of episodic large blooms (det and caco3).

Applying the sea-surface chlorophyll values throughout the upper 100 m is a big assumption about the vertical structure of phytoplankton distribution. Another assumption is the empirical relationship between phytoplankton and zooplankton biomass. To me, these assumptions introduce additional sources of uncertainty in the model.

Anyway, I don't think the solution will be sensitive to these choices at interannual to decadal timescales of our simulations.

hakaseh · 2021-10-18T04:58:58Z

/g/data/v45/hh0162/projects/icebgc/prep_omip2/input_om2-bgc/*deg*/i2o.nc initialise nit_io=0.1 and alg_io=0.1, but /g/data/v45/hh0162/projects/icebgc/prep_omip2/input_om2-bgc/*deg*/o2i.nc initialise ssn_i=1 and ssalg_i =1

Are these values OK? It seems odd that nutrient and algae would have the same values.

Should ssn_i be derived from no3 in /g/data/v45/hh0162/projects/icebgc/prep_omip2/input_om2-bgc/*deg*/csiro_bgc.res.nc? This varies over several orders of magnitude, so a constant 1 seems odd.

Should ssalg_i be derived from phy in /g/data/v45/hh0162/projects/icebgc/prep_omip2/input_om2-bgc/*deg*/csiro_bgc.res.nc? This is currently 0.01 but may itself need changing.

I don't think I understand what i2o.nc and o2i.nc represent. Are they the initial conditions for boundary fluxes? I thought they were arbitrary (as seen from some of the other variables that have been given a constant value).

hakaseh · 2021-10-18T05:05:56Z

valid_range, longname, standard_name and units attributes are wrong and should be deleted from
/g/data/v45/hh0162/projects/icebgc/prep_omip2/input_om2-bgc/1deg/csiro_bgc.res.nc
/g/data/v45/hh0162/projects/icebgc/prep_omip2/input_om2-bgc/01deg/csiro_bgc.res.nc
/g/data/v45/hh0162/projects/icebgc/prep_omip2/input_om2-bgc/01deg-cycle4/csiro_bgc.res.nc
these attributes are already absent from /g/data/v45/hh0162/projects/icebgc/prep_omip2/input_om2-bgc/025deg/csiro_bgc.res.nc

this is my laziness 😄 i will fix this eventually.

hakaseh · 2021-10-19T21:26:27Z

/g/data/v45/hh0162/projects/icebgc/prep_omip2/input_om2-bgc/*deg*/i2o.nc initialise nit_io=0.1 and alg_io=0.1, but /g/data/v45/hh0162/projects/icebgc/prep_omip2/input_om2-bgc/*deg*/o2i.nc initialise ssn_i=1 and ssalg_i =1
Are these values OK? It seems odd that nutrient and algae would have the same values.

Should ssn_i be derived from no3 in /g/data/v45/hh0162/projects/icebgc/prep_omip2/input_om2-bgc/*deg*/csiro_bgc.res.nc? This varies over several orders of magnitude, so a constant 1 seems odd.

Should ssalg_i be derived from phy in /g/data/v45/hh0162/projects/icebgc/prep_omip2/input_om2-bgc/*deg*/csiro_bgc.res.nc? This is currently 0.01 but may itself need changing.

I don't think I understand what i2o.nc and o2i.nc represent. Are they the initial conditions for boundary fluxes? I thought they were arbitrary (as seen from some of the other variables that have been given a constant value).

just to clarify, i was referring to wnd10_io which was given a constant value. i see that other variables are given spatially variable values.

i just did a test run by increasing ssn_i and ssalg_i in o2i.nc from 1 to 10, and ran the model for 1 day. The difference is negligible (/scratch/v45/hh0162/access-om2-cycle4/control/bgc-mdppm-run-1deg-ryf/archive/w_icebgc_1d_x10/diff_*.nc).
I feel like all of these fields (including wnd10_io) could be set to zero for simplicity (zero flux in the very first time step).

hakaseh · 2021-10-25T23:16:02Z

@aekiss I've just updated i2o.nc and o2i.nc in /g/data/v45/hh0162/projects/icebgc/prep_omip2/input_om2-bgc/*deg*/ (including 01deg-cycle4) with zero values, as proposed in my previous comment above.

And I also reflected this in hh-dev of `input_om2-bgc':
COSIMA/input_om2-bgc@11c18e7

hakaseh · 2021-10-27T20:29:52Z

@aekiss I've created a new branch iamip2-hh for both MOM and CICE, which should be the final code changes from me:
https://github.com/hakaseh/mom/tree/iamip2-hh
https://github.com/hakaseh/cice5/tree/iamip2-hh

aekiss · 2021-10-28T02:04:53Z

Thanks @hakaseh I've compiled executables here for test runs

/g/data/ik11/inputs/access-om2/bin/yatm_0ab7295.exe
/g/data/ik11/inputs/access-om2/bin/fms_ACCESS-OM-BGC_1d9af9d_libaccessom2_0ab7295.x
/g/data/ik11/inputs/access-om2/bin/cice_auscom_18x15.3600x2700_1682p_3a5d05f_libaccessom2_0ab7295.exe
/g/data/ik11/inputs/access-om2/bin/cice_auscom_1440x1080_480p_3a5d05f_libaccessom2_0ab7295.exe
/g/data/ik11/inputs/access-om2/bin/cice_auscom_360x300_24p_3a5d05f_libaccessom2_0ab7295.exe
/g/data/ik11/inputs/access-om2/bin/cice_auscom_3600x2700_722p_3a5d05f_libaccessom2_0ab7295.exe

hakaseh · 2021-10-31T21:17:07Z

good morning @aekiss.

I have updated README of https://github.com/COSIMA/input_om2-bgc/blob/main/README.md. Please review.

I don't seem to have edit access for https://github.com/COSIMA/access-om2/projects/5. i can view but cannot move an item to another column, etc.

aekiss · 2021-11-02T08:02:59Z

Thanks @hakase I have incorporated that into the branch I'm working on
https://github.com/COSIMA/input_om2-bgc/tree/ak-dev
I'll do a PR soon.

Not sure what the issue is with the project board. Might not be able to look at that for a few days.

aekiss · 2021-11-04T10:06:32Z

The new input files in /g/data/ik11/inputs/access-om2/input_bgc_20211104 have fixed the incorrect longnames etc noted above in #11 (comment) and #11 (comment)

hakaseh · 2021-11-05T00:56:58Z

@aekiss should I close this issue/PR since I'm working now on master+bgc? also because i'm getting better at creating issues 😄

hakaseh · 2021-11-09T21:24:16Z

closing this issue as we now have master+bgc. see #13 (comment)

hakase hayashida added 6 commits May 2, 2021 23:36

2021-05-02 23:36:13: Run 0

3179fd2

2021-05-02 23:50:07: Run 0

0e4565e

2021-05-02 23:59:10: Run 0

41227c1

2021-05-03 09:54:38: Run 1

548a76b

2021-05-03 10:04:22: Run 1

1d0ebe7

bgc testing done.

f88bc06

change input file directory for the official release of OM2-BGC.

e2590b3

add bribe tracer diags.

a92ffc3

hakaseh mentioned this pull request Oct 31, 2021

create a new branch for bgc COSIMA/make_diag_table#2

Closed

hakaseh mentioned this pull request Nov 3, 2021

master+bgc #13

Closed

aekiss mentioned this pull request Nov 4, 2021

Make script generate 01deg-cycle4 inputs too? COSIMA/input_om2-bgc#5

Closed

hakaseh closed this Nov 9, 2021

aekiss mentioned this pull request Nov 12, 2021

cycle4 COSIMA/01deg_jra55_iaf#11

Open

BGC included 1deg_jra55_iaf #11

BGC included 1deg_jra55_iaf #11

Conversation

hakaseh commented May 3, 2021

aekiss commented May 6, 2021 • edited Loading

hakaseh commented May 10, 2021 via email

hakaseh commented May 11, 2021

aekiss commented May 11, 2021

aekiss commented May 11, 2021

hakaseh commented May 11, 2021

aekiss commented May 11, 2021

hakaseh commented May 11, 2021

aekiss commented May 11, 2021

hakaseh commented May 11, 2021

aekiss commented May 11, 2021 • edited Loading

hakaseh commented May 11, 2021

hakaseh commented May 11, 2021

hakaseh commented May 12, 2021

aekiss commented May 12, 2021

hakaseh commented May 12, 2021

aidanheerdegen commented May 12, 2021

hakaseh commented May 12, 2021

aekiss commented May 12, 2021

hakaseh commented May 13, 2021

aekiss commented May 20, 2021 • edited Loading

aekiss commented May 20, 2021

aekiss commented Oct 14, 2021

hakaseh commented Oct 15, 2021

aekiss commented Oct 15, 2021

hakaseh commented Oct 15, 2021 via email

aekiss commented Oct 15, 2021

aekiss commented Oct 15, 2021

aekiss commented Oct 15, 2021 • edited Loading

aekiss commented Oct 15, 2021

aekiss commented Oct 15, 2021

aekiss commented Oct 15, 2021 • edited Loading

aekiss commented Oct 15, 2021

aekiss commented Oct 15, 2021 • edited Loading

aekiss commented Oct 15, 2021

hakaseh commented Oct 18, 2021

hakaseh commented Oct 18, 2021

hakaseh commented Oct 18, 2021

hakaseh commented Oct 19, 2021

hakaseh commented Oct 25, 2021

hakaseh commented Oct 27, 2021

aekiss commented Oct 28, 2021 • edited Loading

hakaseh commented Oct 31, 2021

aekiss commented Nov 2, 2021

aekiss commented Nov 4, 2021

hakaseh commented Nov 5, 2021

hakaseh commented Nov 9, 2021

aekiss commented May 6, 2021 •

edited

Loading

aekiss commented May 11, 2021 •

edited

Loading

aekiss commented May 20, 2021 •

edited

Loading

aekiss commented Oct 15, 2021 •

edited

Loading

aekiss commented Oct 15, 2021 •

edited

Loading

aekiss commented Oct 15, 2021 •

edited

Loading

aekiss commented Oct 28, 2021 •

edited

Loading