-
Notifications
You must be signed in to change notification settings - Fork 47
biodensity_feedback: initial commit #9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
I'll suggest: The Travis CI fails - https://travis-ci.org/github/gotm-model/code/builds/721153138 - (can you see the link) - because we have not settled on if CVMix shall be included or not. |
What about:
only one do loop - and no automatic array needed |
but can't be vectorized |
On 8/26/20 9:20 AM, Karsten Bolding wrote:
I'll suggest:
biodensity_feedback --> density_feedback - as the correction does not
need to come from bio.
I would say no. as implemented now, the logical biodensity_feedback only
covers the feedback from fabm. other non-fabm sources can also use the
routine density_correction() [can be called several times per time step
as it just does adding], but they do not use the flag from gotm_fabm.
|
but if you want to emphasize FABM - then call it fabmdensity_feedback - FABM contains non-bio stuff as well. |
On 8/26/20 9:43 AM, Karsten Bolding wrote:
but can't be vectorized
is there any lost in performance by the repeated copy bu=bl?
…
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#9 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC2RV6RASDG2C26NH5BK3QTSCS4IVANCNFSM4QLEBRHQ>.
|
fine with me, but this argument then also applies to the other feedback
switches. I just named it consistent to them.
…On 8/26/20 11:37 AM, Karsten Bolding wrote:
but if you want to emphasize FABM - then call it fabmdensity_feedback
- FABM contains non-bio stuff as well.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#9 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC2RV6WTWFUR7BFSSGSMBATSCTJXNANCNFSM4QLEBRHQ>.
|
Not compared to allocate a new vector and do two loops |
and what about making buoy_corr a static array with if(first)
allocate(buoy_corr)? then we do not re-allocate and keep vectorization.
(BTW: this is also important for getm, so I will post it there as well)
…On 8/26/20 11:42 AM, Karsten Bolding wrote:
On 8/26/20 9:43 AM, Karsten Bolding wrote: but can't be vectorized
is there any lost in performance by the repeated copy bu=bl?
… <#>
— You are receiving this because you authored the thread. Reply to
this email directly, view it on GitHub <#9 (comment)
<#9 (comment)>>,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AC2RV6RASDG2C26NH5BK3QTSCS4IVANCNFSM4QLEBRHQ.
Not compared to allocate a new vector and do two loops
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#9 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC2RV6VCJMIC6M2OWDTLSYDSCTKJ5ANCNFSM4QLEBRHQ>.
|
On 8/26/20 11:54 AM, Knut wrote:
and what about making buoy_corr a static array with if(first)
allocate(buoy_corr)? then we do not re-allocate and keep vectorization.
(BTW: this is also important for getm, so I will post it there as well)
just checked an old getm-devel discussion. there bjarne is in favor of
if(first) allocate.
|
supports feedback from a FABM aggregated standard variable "density_correction" to rho, buoy and NN.