How to make GOTM variables retrievable for FABM?

[Hakase Hayashida]

Hello,

We are developing an sea ice ecosystem (algae) model using GOTM as a host model. As a test run, I am using the Winton ice physics model in uvic_ice branch of GOTM (by setting ice_method = 2 in ice.nml) which seems to reproduce reasonable sea ice for test case "resolute". There are 7 output variables from this model, all starting with "ice_" (e.g. ice_T1, ice_hi). I want to be able to retrieve these variables as external dependencies in FABM to compute ice algae source and sink terms. Which files do I need to modify in GOTM and FABM to make the ice_* variables available to FABM?

Regards,

Hakase Hayashida

University of Victoria

[Jorn Bruggeman]

Hi Hakase,

 

The best place to put this would be in $GOTMDIR/src/gotm/gotm.F90, around line 285. There you can already see lines passing depth and atmospheric variables to FABM. You could use the same syntax to pass ice variables, with something like:

 

call model_fabm%link_horizontal_data(standard_variables_fabm%ice_temperature,ice_T1)

 

To do this, variable ice_T1 must be available, which may mean you need to add a use statement to gotm.F90 for the ice module that declares ice_T1. Also, this variable (ice_T1) will need to be declared with the “target” attribute, to allow FABM to keep a pointer to it.

 

Finally, if you follow the above syntax, you would need to create standard variables for each of your ice-related quantities (e.g., “ice_temperature” used above). You have to see I this makes sense (i.e., whether others would indeed consider them to be some sort of standard variable, definable for any ice model). You could take a look at the CF standard names (http://cfconventions.org/standard-names-26.html) to see if something suitable already exists. If it makes sense to create a standard variable, do so by editing $FABMDIR/util/standard_variables/variables.yaml, then execute $FABMDIR/util/standard_variables/parse_standard_variables.py (but pull in today’s change from the FABM repository first!). This should add your new variables to the fabm_standard_variables module.

 

Alternatively, - and this is much easier, but slightly less future-proof - if it does not (yet) make sense to make these into standard variables, you can just give them any arbitrary name, and substitute that for the standard variable like so:

 

call model_fabm%link_horizontal_data(‘ice_T1’,ice_T1)

 

After following these steps, you should be able to use register_dependency  from biogeochemical models with either the new standard variable or your arbitrary string to get the value of ice variables…

 

Hope this helps,

 

Jorn

 

--
You received this message because you are subscribed to the Google Groups "FABM-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fabm-devel+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Hakase Hayashida]

Hi Jorn,

Thanks for your reply.

I followed your steps (with the latter option, i.e. without creating standard variables) to add the variable "ice_hi" of Winton Ice model. While the compilation went fine, I got the following error message at the beginning of simulation:

 data for dependency "uvic_dms_ice_hi", defined on a horizontal slice of the model domain, have not been provided.

 FATAL ERROR: fabm_check_ready: FABM is lacking required data.

STOP 1

Here are the steps I took:

1. Modified gotm-git/src/gotm/gotm.F90 to be able to retrieve "ice_hi" by adding:
   
   use ice,         only: ice_hi
   call model_fabm%link_horizontal_data('ice_hi',ice_hi)
   
   
2. Modified gotm-git/src/ice/ice.F90 to make "ice_hi" available for gotm.F90 by adding "target":
   
   REALTYPE, public,target                    :: ice_hs,ice_hi
   
   
3. Finally, call "ice_hi" in FABM module by adding:
   
   call self%register_dependency(self%id_ice_hi,'ice_hi')

What am I missing here?

Regards,

Hakase

[Jorn Bruggeman]

Hi Hakase,

 

That all sounds good. What is the data type of id_ice_hi in the biogeochemical model? It should be of type_horizontal_dependency_id.

 

Cheers,

[Hakase Hayashida]

Hi Jorn,

Yes, I have it as type_horizontal_dependency_id.

Hakase

[Jorn Bruggeman]

Hi Hakase,

 

Try replacing ‘ice_hi’ by type_horizontal_standard_variable(name=’ice_hi’) in both gotm.F90 and in the biogeochemical model. You might need to add “use fabm_standard_variables”. Does that help?

[Hakase Hayashida]

Hi Jorn,

Great! it worked after replacing ‘ice_hi’ and adding use fabm_standard_variables. Thanks a lot!

Cheers,

Hakase

On Jun 3, 2014, at 7:00 AM, Jorn Bruggeman <jo...@bolding-burchard.com> wrote:

Hi Hakase,

 

Try replacing ‘ice_hi’ by type_horizontal_standard_variable(name=’ice_hi’) in both gotm.F90 and in the biogeochemical model. You might need to add “use fabm_standard_variables”. Does that help?

 

Cheers,

 

Jorn

 

[Jorn Bruggeman]

Hi Hakase,

 

Great! Sorry for putting you on the wrong track originally. I forgot that a since a while ago, all communication between hydrodynamic and biogeochemical models happens through standard variable objects (no more raw strings).

[Hakase Hayashida]

Hi Jorn,

I think this method does not retrieve the variable I am looking for. I've noticed today, by comparing the surface ice temperature provided by GOTM with that provided by FABM (I save the variable as a horizontal diagnostic variable after retrieving it by following the method described in this topic), that the two outputs were not the same (the former being correct, and the latter incorrect). I thought this was happening only to our ice model branch (ns_ice), but I confirmed that's not the case by comparing the variable "ice_hi" between GOTM and FABM in master's uvic_ice branch. In this case, FABM retrieves a missing value when I try to access "ice_hi".

Cheers,

Hakase

On Tuesday, June 3, 2014 10:05:33 AM UTC-7, Jorn Bruggeman wrote:

Hi Hakase,

 

Great! Sorry for putting you on the wrong track originally. I forgot that a since a while ago, all communication between hydrodynamic and biogeochemical models happens through standard variable objects (no more raw strings).

 

Hakase

 

To unsubscribe from this group and stop receiving emails from it, send an email to fabm-devel+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "FABM-devel" group.

To unsubscribe from this group and stop receiving emails from it, send an email to fabm-devel+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "FABM-devel" group.

To unsubscribe from this group and stop receiving emails from it, send an email tofabm-devel+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "FABM-devel" group.

To unsubscribe from this group and stop receiving emails from it, send an email to fabm-devel+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Jorn Bruggeman]

Hi Hakase,

 

Did this problem pop up only recently, or do you think it has never worked in the past? One thing that comes to mind: if you’d register the horizontal diagnostic with the exact same name as the dependency, or if you assign it the same “standard variable” identity, FABM would assume you want the diagnostic to serve as the source of the dependency. That could give you such missing values… Any idea whether that could be the cause?

 

Cheers,

 

Jorn

 

 

Hakase

 

To unsubscribe from this group and stop receiving emails from it, send an email tofabm-devel+...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

 

-- 
You received this message because you are subscribed to the Google Groups "FABM-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fabm-devel+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

 

--

You received this message because you are subscribed to the Google Groups "FABM-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fabm-devel+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "FABM-devel" group.

To unsubscribe from this group and stop receiving emails from it, send an email to fabm-devel+...@googlegroups.com.

[Hakase Hayashida]

Hi Jorn,

Thank you for your quick reply.

I believe this problem has existed ever since I first tried it out in June, but at that time, I was only testing to see if I could compile and run the code without an error (and I was able to). I recently started working on implementing the ice algae model and then now only noticed that such problem exists, as the ice algae was behaving weird (and I confirmed it was due to the values of these dependency variables).

The answer to your question is no: I have different IDs for diagnostic and dependency variables for ns_ice branch. However, I might have used the same name for the uvic_ice branch, but it was just a quick test..

One other thing I noticed now is that they all produce the same output which looks like this:

 

This is strange because I give different names and variables for each ice variable. For example in gotm/gotm.F90: 

      call model_fabm%link_horizontal_data(type_horizontal_standard_variable(name='ice_hi'),ice_hi)

      call model_fabm%link_horizontal_data(type_horizontal_standard_variable(name='ice_tb'),ice_uvic_tb)

And in the ice algae model:

      call self%register_horizontal_dependency(self%id_temp,type_horizontal_standard_variable(name='ice_tb'))

      call self%register_horizontal_dependency(self%id_ice_hi,type_horizontal_standard_variable(name='ice_hi'))

      

Any idea why they produce the same values?

Cheers,

Hakase

On Sep 23, 2014, at 2:40 PM, Jorn Bruggeman <jo...@bolding-burchard.com> wrote:

Hi Hakase,

 

Did this problem pop up only recently, or do you think it has never worked in the past? One thing that comes to mind: if you’d register the horizontal diagnostic with the exact same name as the dependency, or if you assign it the same “standard variable” identity, FABM would assume you want the diagnostic to serve as the source of the dependency. That could give you such missing values… Any idea whether that could be the cause?

 

Cheers,

 

Jorn

 

From: fabm-...@googlegroups.com [mailto:fabm-...@googlegroups.com] On Behalf Of Hakase Hayashida
Sent: 23 September 2014 21:00
To: fabm-...@googlegroups.com
Subject: Re: fabm-devel:788 How to make GOTM variables retrievable for FABM?

 

Hi Jorn,

 

I think this method does not retrieve the variable I am looking for. I've noticed today, by comparing the surface ice temperature provided by GOTM with that provided by FABM (I save the variable as a horizontal diagnostic variable after retrieving it by following the method described in this topic), that the two outputs were not the same (the former being correct, and the latter incorrect). I thought this was happening only to our ice model branch (ns_ice), but I confirmed that's not the case by comparing the variable "ice_hi" between GOTM and FABM in master's uvic_ice branch. In this case, FABM retrieves a missing value when I try to access "ice_hi".

 

Cheers,

Hakase

On Tuesday, June 3, 2014 10:05:33 AM UTC-7, Jorn Bruggeman wrote:

Hi Hakase,

 

Great! Sorry for putting you on the wrong track originally. I forgot that a since a while ago, all communication between hydrodynamic and biogeochemical models happens through standard variable objects (no more raw strings).

 

Cheers,

 

Jorn

 

[Jorn Bruggeman]

Hi Hakase,

 

I’ve very quickly tested this (provide these standard variables from gotm, and retrieve their values from a FABM model) but did not experience any problems. Could you send a listing of your FABM model code with at least the section that declares the ids, the section that registers the dependencies and diagnostic variables, and the section that retrieves and sets their values?

 

Also make sure you have the latest FABM code (yesterday’s update could be relevant)

 

Cheers

To unsubscribe from this group and stop receiving emails from it, send an email tofabm-devel...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

 

-- 
You received this message because you are subscribed to the Google Groups "FABM-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fabm-devel+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "FABM-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fabm-devel+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "FABM-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fabm-devel+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

 

-- 
You received this message because you are subscribed to the Google Groups "FABM-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fabm-devel+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

 

--

[Hakase Hayashida]

Hi Jorn,

Did you use type_horizontal_standard_variable(name=‘ice_temp’) or standard_variables_fabm%ice_temperature?

Here is my code:

! Declare horizontal diagnostic variables

      type (type_horizontal_diagnostic_variable_id) :: id_fgrow,id_fmort,id_fmelt,id_fno3_up,id_fsi_up,id_fskel_no3,id_fskel_si,id_l_ice,id_l_lig,id_l_no3,id_l_sil

! Declare environmental variables

      type (type_dependency_id) :: id_par,id_no3SW,id_siSW

      type (type_horizontal_dependency_id) :: id_temp,id_ice_hi,id_botmelt,id_botgrowth,id_utaui

.

.

.

! Register diagnostic variables

      call self%register_horizontal_diagnostic_variable(self%id_fgrow,'fgrow','mg Chl-a per day','ice algal growth rate')

      call self%register_horizontal_diagnostic_variable(self%id_fmort,'fmort','mg Chl-a per day','ice algal mortality rate')

      call self%register_horizontal_diagnostic_variable(self%id_fmelt,'fmelt','mg Chl-a per day','ice algal melting rate')

      call self%register_horizontal_diagnostic_variable(self%id_fno3_up,'fno3_up','uM per day','ice algal no3 uptake rate')

      call self%register_horizontal_diagnostic_variable(self%id_fsi_up,'fsi_up','uM per day','ice algal si uptake rate')

      call self%register_horizontal_diagnostic_variable(self%id_fskel_no3,'fskel_no3','uM per day','no3 flux to skeletal layer')

      call self%register_horizontal_diagnostic_variable(self%id_fskel_si,'fskel_si','uM per day','si flux to skeletal layer')

      call self%register_horizontal_diagnostic_variable(self%id_l_ice,'L_ig','-','Limitation due to ice growth/melt')

      call self%register_horizontal_diagnostic_variable(self%id_l_lig,'L_light','-','Limitation due to light')

      call self%register_horizontal_diagnostic_variable(self%id_l_no3,'L_no3','-','Limitation due to nitrate')

      call self%register_horizontal_diagnostic_variable(self%id_l_sil,'L_si','-','Limitation due to silicate')

! Register environmental variables

      call self%register_horizontal_dependency(self%id_temp,type_horizontal_standard_variable(name='tb'))

      call self%register_horizontal_dependency(self%id_ice_hi,type_horizontal_standard_variable(name='hi'))

      call self%register_dependency(self%id_par,standard_variables%downwelling_photosynthetic_radiative_flux)

      call self%register_horizontal_dependency(self%id_botmelt,type_horizontal_standard_variable(name='botmelt'))

      call self%register_horizontal_dependency(self%id_botgrowth,type_horizontal_standard_variable(name='botgrowth'))

      call self%register_horizontal_dependency(self%id_utaui,type_horizontal_standard_variable(name='hi'))!!!??? should be 'u_taus'

      call self%register_dependency(self%id_no3SW,'uvic_eco_no3')

      call self%register_dependency(self%id_siSW,'uvic_eco_sil')

      call self%request_coupling(self%id_no3SW,'uvic_eco_no3')

      call self%request_coupling(self%id_siSW,'uvic_eco_sil')

.

.

.

   _GET_HORIZONTAL_(self%id_chlia,chlia)

   _GET_HORIZONTAL_(self%id_no3,no3)

   _GET_HORIZONTAL_(self%id_si,si)

   _GET_HORIZONTAL_(self%id_temp,temp)

   _GET_HORIZONTAL_(self%id_ice_hi,ice_hi)

   _GET_(self%id_par,par)

   _GET_(self%id_no3SW,no3SW)

   _GET_(self%id_siSW,siSW)

   _GET_HORIZONTAL_(self%id_botmelt,botmelt)

   _GET_HORIZONTAL_(self%id_botgrowth,botgrowth)

   _GET_HORIZONTAL_(self%id_utaui,utaui)

.

.

.

   _SET_HORIZONTAL_DIAGNOSTIC_(self%id_fgrow,fgrow*self%spd)

   _SET_HORIZONTAL_DIAGNOSTIC_(self%id_fmort,fmort*self%spd)

   _SET_HORIZONTAL_DIAGNOSTIC_(self%id_fmelt,fmelt*self%spd)

   _SET_HORIZONTAL_DIAGNOSTIC_(self%id_fskel_no3,fskel_no3*self%spd)

   _SET_HORIZONTAL_DIAGNOSTIC_(self%id_fskel_si,fskel_si*self%spd)

   _SET_HORIZONTAL_DIAGNOSTIC_(self%id_fno3_up,fno3_up*self%spd)

   _SET_HORIZONTAL_DIAGNOSTIC_(self%id_fsi_up,temp)!fsi_up*self%spd)

   _SET_HORIZONTAL_DIAGNOSTIC_(self%id_l_ice,ice_hi)!L_ig)

   _SET_HORIZONTAL_DIAGNOSTIC_(self%id_l_lig,ier)!L_light)

   _SET_HORIZONTAL_DIAGNOSTIC_(self%id_l_no3,botgrowth)!L_no3)

   _SET_HORIZONTAL_DIAGNOSTIC_(self%id_l_sil,botmelt)!L_si)

Cheers,

Hakase

On Sep 24, 2014, at 9:01 AM, Jorn Bruggeman <jo...@bolding-burchard.com> wrote:

Hi Hakase,

 

I’ve very quickly tested this (provide these standard variables from gotm, and retrieve their values from a FABM model) but did not experience any problems. Could you send a listing of your FABM model code with at least the section that declares the ids, the section that registers the dependencies and diagnostic variables, and the section that retrieves and sets their values?

 

Also make sure you have the latest FABM code (yesterday’s update could be relevant)

 

Cheers

 

Jorn

 

From: fabm-...@googlegroups.com [mailto:fabm-...@googlegroups.com] On Behalf Of Hakase Hayashida
Sent: 24 September 2014 03:08
To: fabm-...@googlegroups.com
Subject: Re: fabm-devel:789 How to make GOTM variables retrievable for FABM?

 

Hi Jorn,

 

Thank you for your quick reply.

 

I believe this problem has existed ever since I first tried it out in June, but at that time, I was only testing to see if I could compile and run the code without an error (and I was able to). I recently started working on implementing the ice algae model and then now only noticed that such problem exists, as the ice algae was behaving weird (and I confirmed it was due to the values of these dependency variables).

 

The answer to your question is no: I have different IDs for diagnostic and dependency variables for ns_ice branch. However, I might have used the same name for the uvic_ice branch, but it was just a quick test..

 

One other thing I noticed now is that they all produce the same output which looks like this:

 

<image001.png>

 

This is strange because I give different names and variables for each ice variable. For example in gotm/gotm.F90: 

 

      callmodel_fabm%link_horizontal_data(type_horizontal_standard_variable(name='ice_hi'),ice_hi)

      callmodel_fabm%link_horizontal_data(type_horizontal_standard_variable(name='ice_tb'),ice_uvic_tb)

 

And in the ice algae model:

 

      callself%register_horizontal_dependency(self%id_temp,type_horizontal_standard_variable(name='ice_tb'))

      callself%register_horizontal_dependency(self%id_ice_hi,type_horizontal_standard_variable(name='ice_hi'))

      

[Dr. Carsten Lemmen]

Dear FABM developers/users,

We would like to specifically invite your community to contribute with scientific and technical contributions to our ASLO 2015 session

102 - MODULAR FRAMEWORKS IN AQUATIC SCIENCES

Integrated model systems usually combine different submodels within one monolithic code. These monolithic systems, however, make it difficult to exchange and independently maintain submodels, to devise model intercomparison, or to share specific expertise. Modular frameworks define interfacing standards and enable coupling software that exhibits high-level modularity. For example, the Framework for Aquatic Biogeochemical Models (FABM) can link process descriptions within one Earth System domain. Alternatively, models for different compartments (e.g., water column, sea-floor sediments) can be coupled through systems such as the Earth System Modeling Framework (ESMF). Within such frameworks, various models can communicate with each other and the environmental context in a flexible way, which makes it possible to exchange single modules or to better integrate modules from different sources. Model complexity then better reflects the need of the specific scientific problem at hand. This session invites contributions that document model studies that cross different Earth System domains (e.g., sediment, pelagics) or process areas (e.g., geochemistry, vertebrate ecology) which were made in a modular way. The presentations should highlight arising potentials of modular coupling for freshwater or marine ecosystem modeling.

http://www.sgmeet.com/aslo/granada2015/sessionschedule.asp?SessionID=102

Please consider submitting your abstracts to our session.
Kind regards, and sorry for cross-postings,

Carsten Lemmen



—
=> PostDoc in benthic-pelagic ecosystem modeling (July 13, open until filled): http://tinyurl.com/oxsyvo6
=> ASLO modeling session http://tinyurl.com/nrbeo43

Dr. rer. nat. Carsten Lemmen
Environmental Scientist

Helmholtz Zentrum Geesthacht
Centre for Materials and Coastal Research GmbH
Institute for Coastal Research - System Analysis & Modeling
Ecosystem Modeling (KSE)
Max-Planck-Str.1, 21502 Geesthacht, Germany

Tel.: +49 4152 87-2013 / Fax: -2020 / Secretary: -1526
Building 11, 1st floor, room 131
Email: carsten...@hzg.de
Internet: http://www.hzg.de
Messaging: skype://platipodium or aim://platipodium

My email is as private as regular mail, please 'put it in an envelope'
by GPG encryption with my public key id 9249e2e0.

Geschäftsführer: Prof. Dr. W. A. Kaysser, Dipl.-Ing. M. Ganß
Vorsitzender des Aufsichtsrates: Ministerialdirigent W. Kraus
Amtsgericht Lübeck - HRB 285 GE, USt.IDNr.: DE 135 131 669

Helmholtz-Zentrum Geesthacht
Zentrum für Material- und Küstenforschung GmbH
Max-Planck-Straße 1 I 21502 Geesthacht I Deutschland/Germany

Geschäftsführer/Board of Management: Prof. Dr. Wolfgang Kaysser, Dipl.-Ing. Michael Ganß
Vorsitzender des Aufsichtsrates/Chairman of the Supervisory Board: MinDirig Wilfried Kraus
Amtsgericht Lübeck HRB 285 GE (Register Court)
Internet: http://www.hzg.de

[Hakase Hayashida]

Hi Jorn,

I was able to retrieve the correct value when I used the first method you suggested in the beginning of this forum topic (i.e. adding the variable to the standard_variable list). I believe the method 2 does not work. Anyway, I am happy that it works now.

Cheers,

Hakase

[Jorn Bruggeman]

Hi Hakase,

Glad it works for you. Strangely, I tested by explicitly providing type_horizontal_standard_variable(name='tb') instead of adding it to the standard variables, and that worked fine for me as long as the names were identical on the GOTM and FABM sides.

 

I wouldn’t mind looking into this issue further, but as I see  no possible causes in the code snippets you sent, I could do that only if I had the complete GOTM/FABM code that failed for you. It’d be great if you could provide that, but I appreciate you may be satisfied that it works now, and prefer to move on…

[Karsten Bolding]

I think Hakase has a repository on SF - correct me if I'm wrong Hakase. Thats how it was setup when I was in Victoria.

Karsten

[Hakase Hayashida]

Hi Karsten, Jorn,

Yes, I have and use my repositories on SF which I set up with you, Karsten :)

Jorn, I would really appreciate if you could look into the issue, but I am also OK with the current solution. Anyway, I will send you the links to my GOTM/FABM repositories and other relevant information for testing later today.

Cheers,

Hakase

[Jorn Bruggeman]

Hi all,

 

Just to let you know that this issue (custom standard variables not being coupled correctly) has now been fixed. It was due to changes committed on 23 September 2014, and has been fixed as of 10 October 2014. Only gfortran was affected, ifort was not.

 

Hakase, thanks very much for testing, and for making your code available!

[Hakase Hayashida]

Hi Jorn,

I was wondering if a bulk variable of GOTM could be added to the list of standard variables by following the below method you suggested to me a while ago. So far, I had been dealing with horizontal variables only, and the method worked fine. But now I need to have access to u and v (ocean currents) in FABM, and I followed the same method as I would for horizontal variables, except I replaced the word “horizontal" with “bulk” such as this in gotm/gotm.F90:

call model_fabm%link_bulk_data(standard_variables_fabm%zonal_current,u)

 

The model compiles fine for both FABM and GOTM, but when I run the model, I get the following error:

FATAL ERROR: fabm_link_bulk_data: dimensions of FABM domain and provided array do not match for variable zonal_current.

 

I am assuming this is not the right method for bulk variables?

Thanks,

Hakase

[Jorn Bruggeman]

Hi Hakase,

 

The method you are using is fine. The issue here is that most 1D arrays in GOTM, including u and v, have dimensions 0:nlev, with element 0 remaining unused (background: 0:nlev is used for variables defined at the layer interfaces, 1:nlev for variables at the layer centres). FABM therefore operates on elements 1:nlev only, and the following should work:

 

call model_fabm%link_bulk_data(standard_variables_fabm%zonal_current,u(1:nlev))

 

Cheers,

 

Jorn

 

From: fabm-...@googlegroups.com [mailto:fabm-...@googlegroups.com] On Behalf Of Hakase Hayashida

Sent: 30 July 2015 07:43
To: fabm-...@googlegroups.com

[Hakase Hayashida]

Hi Jorn,

Thanks! The method you suggested works.

Hakase