ocean_bt_visc_rem_producer_on Function

public pure function ocean_bt_visc_rem_producer_on(cfg) result(on)

D1 follow-up: is the visc_rem PRODUCER needed, independent of the (retired) weighted BT-correction fold? .true. whenever ANY real consumer is on — forcing_visc_rem/renorm_visc_rem/ bt_rem_from_visc_rem (each already .or.-ed with visc_rem_chain by their own helper) — or the legacy correction_visc_rem field itself, so a test that constructs cfg directly and sets that field alone (bypassing the nml retirement check) still gets a live producer. This is what configure_ocean_bt wires into bt_work%bt_visc_rem_producer, which vmix_apply_in_stage’s do_remnant reads — NOT bt_work%bt_correction_visc_rem, which now drives ONLY the weighted-fold dispatch in apply_bt_correction (and is never set by visc_rem_chain).

Arguments

Type IntentOptional Attributes Name
type(config_t), intent(in) :: cfg

Return Value logical


Calls

proc~~ocean_bt_visc_rem_producer_on~~CallsGraph proc~ocean_bt_visc_rem_producer_on ocean_bt_visc_rem_producer_on proc~ocean_bt_forcing_visc_rem_on ocean_bt_forcing_visc_rem_on proc~ocean_bt_visc_rem_producer_on->proc~ocean_bt_forcing_visc_rem_on proc~ocean_bt_rem_from_visc_rem_on ocean_bt_rem_from_visc_rem_on proc~ocean_bt_visc_rem_producer_on->proc~ocean_bt_rem_from_visc_rem_on proc~ocean_bt_renorm_visc_rem_on ocean_bt_renorm_visc_rem_on proc~ocean_bt_visc_rem_producer_on->proc~ocean_bt_renorm_visc_rem_on

Called by

proc~~ocean_bt_visc_rem_producer_on~~CalledByGraph proc~ocean_bt_visc_rem_producer_on ocean_bt_visc_rem_producer_on proc~configure_ocean_bt configure_ocean_bt proc~configure_ocean_bt->proc~ocean_bt_visc_rem_producer_on proc~validate_config validate_config proc~validate_config->proc~ocean_bt_visc_rem_producer_on proc~build_pending_handle build_pending_handle proc~build_pending_handle->proc~validate_config proc~engine_setup engine_setup proc~engine_setup->proc~configure_ocean_bt proc~complete_ocean_create complete_ocean_create proc~complete_ocean_create->proc~engine_setup proc~driver_run_ocean driver_run_ocean proc~driver_run_ocean->proc~engine_setup proc~driver_validate driver_validate proc~driver_validate->proc~engine_setup proc~rdb_ocean_create_from_string rdb_ocean_create_from_string proc~rdb_ocean_create_from_string->proc~build_pending_handle proc~rdb_ocean_create_from_string->proc~complete_ocean_create proc~rdb_ocean_create_pending rdb_ocean_create_pending proc~rdb_ocean_create_pending->proc~build_pending_handle proc~driver_run driver_run proc~driver_run->proc~driver_run_ocean proc~rdb_ocean_create_finalize rdb_ocean_create_finalize proc~rdb_ocean_create_finalize->proc~complete_ocean_create

Source Code

   pure function ocean_bt_visc_rem_producer_on(cfg) result(on)
      !! D1 follow-up: is the visc_rem PRODUCER needed, independent of
      !! the (retired) weighted BT-correction fold?  `.true.` whenever
      !! ANY real consumer is on — `forcing_visc_rem`/`renorm_visc_rem`/
      !! `bt_rem_from_visc_rem` (each already `.or.`-ed with
      !! `visc_rem_chain` by their own helper) — or the legacy
      !! `correction_visc_rem` field itself, so a test that constructs
      !! `cfg` directly and sets that field alone (bypassing the nml
      !! retirement check) still gets a live producer.  This is what
      !! `configure_ocean_bt` wires into `bt_work%bt_visc_rem_producer`,
      !! which `vmix_apply_in_stage`'s `do_remnant` reads — NOT
      !! `bt_work%bt_correction_visc_rem`, which now drives ONLY the
      !! weighted-fold dispatch in `apply_bt_correction` (and is never
      !! set by `visc_rem_chain`).
      type(config_t), intent(in) :: cfg
      logical :: on
      on = cfg%ocean%bt%correction_visc_rem .or. ocean_bt_forcing_visc_rem_on(cfg) &
           .or. ocean_bt_renorm_visc_rem_on(cfg) .or. ocean_bt_rem_from_visc_rem_on(cfg)
   end function ocean_bt_visc_rem_producer_on