biodensity_feedback: initial commit

[knutaros]

supports feedback from a FABM aggregated standard variable "density_correction" to rho, buoy and NN.

[bolding]

I'll suggest:
biodensity_feedback --> density_feedback - as the correction does not need to come from bio.

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.

[bolding]

What about:

   
   r2b = -gravity / rho_0
   rho(nlev) = rho(nlev) + rho_corr(nlev)
   bu=rho_corr(nlev)*r2b
   buoy(nlev) = buoy(nlev) + bu
   do i=nlev-1,1,-1
      rho(i) = rho(i) + rho_corr(i)
      bl = rho_corr(i) * r2b
      buoy(i) = buoy(i) + bl 
      dz = _HALF_ * ( h(i) + h(i+1) )
      NN(i) = NN(i) + ( bu - bl ) / dz
      bu = bl
   end do

only one do loop - and no automatic array needed

[bolding]

but can't be vectorized

[knutaros]

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.

[bolding]

but if you want to emphasize FABM - then call it fabmdensity_feedback - FABM contains non-bio stuff as well.

[knutaros]

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>.

[knutaros]

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>.

[bolding]

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.

Not compared to allocate a new vector and do two loops

[knutaros]

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>.

[knutaros]

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.