Comments (10)
That looks right to me. If I understand logic then flwup_ai
in history is (flwout/aice)*aice
. A minor point is that floating point arithmetic does not guarantee that (flwout/aice)*aice == flwout
. Thus splitting flwout
into two versions, one for the coupler and the other for internal use and history would improve the BFBness of history archived in double precision (default in MPAS?).
from cice.
I think we should have a conversation about this. It has just come up again in the context of the ponds. So, the pond fraction is:
apond = sum(apondn(n)*aicen(n)), n = 1, ncat
However, there is a history variable apond_ai. That is, we take apond*aice. However, do we ever divide apond by aice in the code? If not, that means apond_ai has aice multiplied twice effectively. We have a couple variables like this that are not sent to the coupler and hence are not scaled.
from cice.
Note that I am using apondn as the short form for trcrn(:,:,nt_apnd,:,:) here.
from cice.
Pinging @zswolff
from cice.
Actually, when level ponds are turned on then apond and apond_ai are:
if (f_apond(1:1)/= 'x') &
call accum_hist_field(n_apond, iblk, &
trcr(:,:,nt_alvl,iblk) * trcr(:,:,nt_apnd,iblk), a2D)
if (f_apond_ai(1:1)/= 'x') &
call accum_hist_field(n_apond_ai, iblk, &
aice(:,:,iblk) &
* trcr(:,:,nt_alvl,iblk) * trcr(:,:,nt_apnd,iblk), a2D)
from cice.
I'm not seeing the problem here. E.g. at the end of compute_ponds_lvl, the tracer array is reloaded correctly:
apnd = apondn / (aicen*alvl_tmp)
That's also done for the cesm and topo cases. History uses the tracer fields directly, as you note above, and there's a special subroutine for merging (aggregating) tracer fields based on their dependencies. Can you be a little more specific about what you are looking at in the code?
from cice.
Thanks for highlighting this. I guess I didn't realize that this was done in the melt pond code. I do think it is worth making sure all of our _ai and non _ai fields are done correctly.
from cice.
Actually, I looked at the aggregate subroutine which does indeed aggregate (merge) the tracers according to their dependencies. For example for the level ice:
atrcr(:,:,:) = atrcr(:,:,:) + trcrn(:,:,nt_apnd,:,n)*trcrn(:,:,nt_alvl,:,n)*aicen(:,:,:,n)
However, I don't see where trcr(:,:,nt_apnd,:) is divided by the gridcell trcr(:,:,nt_alvl,:) and aice(:,:,:). Then it is multiplied by these in history ... I'm very confused.
from cice.
I'm still not sure what you're looking at. There are two aggregate routines now, aggregate_area (which only does area, not tracers) and icepack_aggregate, which does everything. The division is done in another routine called at the end of icepack_aggregate, subroutine icepack_compute_tracers.
Which version of the code are you looking at? I'm not finding the line of code above:
bash-3.2$ grep -R "atrcr(:,:,:) = atrcr(:,:,:) + trcrn" cicecore/* icepack/*
bash-3.2$
Also, the history output uses the trcr arrays directly, not atrcr.
from cice.
This has come up yet again in #764. Cleaning up the coupling/non-coupling fields/fieldnames should be a higher priority. In #764, we have decided to use _iavg to indicate a field that is "per ice area" (divided by aice). We'll want to go thru the code carefully to instantiate new fields with the suffix _iavg, refactor subroutine scale_fluxes, and then review where those fields are used elsewhere in the code.
from cice.
Related Issues (20)
- dsnow optional argument in icepack_step_therm1 HOT 2
- evp1d performance evaluation
- Support netcdf-4 compression & chunking HOT 1
- hist_avg on multiple streams writes the same filenames when .false. HOT 9
- Potential instability related to explicit treatment of Coriolis for C-grid HOT 3
- Arguments in update_state need if present. HOT 2
- dynamics U points are active when T points are not HOT 5
- Commit/PR process HOT 3
- PIO and hdf5 failures HOT 6
- Test various restart formats and add Derecho port that uses pio spack HOT 1
- tripole initial/restart file with inconsistent values on the tripole seam HOT 15
- CICE C-grid crash on 1/12 degree tripole HOT 11
- Can we remove `nprocs` from `ice_in` ? HOT 6
- FSD heat / water / salt conservation
- PIO createfile where path is a symlink
- Minor modifications required in documentation HOT 3
- Unnecessary calculations for uvel, vvel for the C-grid HOT 5
- Questions about the computer configuration required to run HOT 1
- Make a_min and m_min adjustable
- NCAR derecho compilers HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from cice.