Move soil water and N uptake methods out of root, into soil models

[HamishBrownPFR]

@hut104 @hol353 @fai04d @rcichota

This is what I think. Anyone else agree?

Currently the soil arbitrator asks the plant for an uptake, the plant asks the root for an uptake and sends it through. Currently root.cs uses kl to calculate uptake. This is a SoilWat specific approach and when we implement other soil water models we are going to need to program variants in there. For this reason it would be better to put the uptake into the soil model so it can apply its own uptake methods and send that directly to the arbitrator. It is also less convoluted as the coms are direct from soil to arbitrator (or soil to root to get root properties affecting uptake) and back again.

[hut104]

Hi all, I’m not sure this can be done easily. Calculation of potential uptakes requires plant information and each plant model can use different approaches. E.g. For example, in the case of N, there are preferences between NO3 and NH4 in some species, and some algorithms require rld and root radius. If we end up arbitrating multiple nutrients together it would also get trickier. I also think we’d get a stack of pushback from other APSIM Crop folk. I think the crops can calculate the potential uptake, the soil arbitrator can do the actuals, the soils could do the actual removal of masses. That’s my two bits worth, Neil.

From: Hamish Brown [mailto:notifications@github.com] Sent: Friday, 9 September 2016 4:58 AM To: APSIMInitiative/ApsimX ApsimX@noreply.github.com Cc: Huth, Neil (A&F, Toowoomba) Neil.Huth@csiro.au; Mention mention@noreply.github.com Subject: [APSIMInitiative/ApsimX] Move soil water and N uptake methods out of root, into soil models (#1155)

@hut104https://github.com/hut104 @hol353https://github.com/hol353 @fai04dhttps://github.com/fai04d @rcichotahttps://github.com/rcichota

This is what I think. Anyone else agree?

Currently the soil arbitrator asks the plant for an uptake, the plant asks the root for an uptake and sends it through. Currently root.cs uses kl to calculate uptake. This is a SoilWat specific approach and when we implement other soil water models we are going to need to program variants in there. For this reason it would be better to put the uptake into the soil model so it can apply its own uptake methods and send that directly to the arbitrator. It is also less convoluted as the coms are direct from soil to arbitrator (or soil to root to get root properties affecting uptake) and back again.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/APSIMInitiative/ApsimX/issues/1155, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ALVK2mNqxpntiUT7yLTeJrdAhM7reUMlks5qoFqygaJpZM4J4VMN.

[HamishBrownPFR]

The need for different models to use different information can be overcome easy enough with an interface??? Similar to how microclimate works, there is an interface which provides crop information (lai, height cover etc) and microclimate uses this to calculate demand. In theory we could sub a microclimate alternative in that works through the same interface. We could also have an interface with root properties (depth, rld[], rootRadius[] ets, Nh4 and No3 uptake prarameters) and then soil models can use these to do uptake if they need them. It is going to get messy in root when we have to introduce more code to deal with SWIM uptake methods and more code again to deal with what ever I implement to do uptake in the multipore model.
For those who want to keep using the kl approach as is currently done, they will not see any difference apart from where the code is located, in soilWat rather than in plant. It seems sensible to me that this is where the kl uptake code should sit anyway because the kl approach is specific to soilwat??

[rcichota]

I agree with Neil that it will be difficult, and placing the uptake in one place may restrict the plant (or soil) modeler. In my view the plant sets demand, but the N amount (or water, etc) available and eventually taken up is defined by both plant and soil. Currently only plant does it (the SoilArbitrator only handles in case of multiple crops). If we move the uptake to the soil only then we'll get into problems Neil talked. But with different soil modules we'll need something better than we currently have. especially if we want to have the soil module having a say on how much stuff can be taken up. My idea is having variables like PlantAvailalbeNO3[] or SolutionNO3[], instead of simply NO3[], so the soil can have some control over the amount available, the plant then uses this values to define its own availability. This allows the soil module to limit plant uptake if a solute is adsorbed to soil or in immobile fraction etc., but leaves the plant model to have its own approach on how to handle the actual available amount. This adds more variables, but allows greater flexibility for changes in approaches for both soil and plant modules. I have to use this approach in SoilNitrogen to limit plant uptake from inaccessible urine patches, for example. That's my bit for today

[HamishBrownPFR]

Uptake is an interaction of plant and soil factors but for model implementation we have to put it some where. Currently in plant but I am arguing that from a coding point of view it will be tidier to put it in soil with a nice interface to plant to get the information needed. May be I am not understanding the problems you guys are referring too.

[HamishBrownPFR]

Coming back to this after some time.

The Method below is from Root organ where soil water supply is calculated

The highlighted bits are SoilWat specific. For the Multipore water uptake will be done differently. @hol353 Should we put if statements into root to determine what soil water model it is dealing with and apply the appropriate calculations, or should this supply calculation be moved into the soil models. @fai04d how are you doing this for SWIM??

[hut104]

Note that in NextGen the uptakes are essentially calculated by the SoilArbitrator. Plants only calculate potential values. In the short term, I’d imagine that we won’t put uptake into SWIM for that reason.

From: Hamish Brown [mailto:notifications@github.com] Sent: Tuesday, 14 February 2017 6:21 AM To: APSIMInitiative/ApsimX ApsimX@noreply.github.com Cc: Huth, Neil (A&F, Toowoomba) Neil.Huth@csiro.au; Mention mention@noreply.github.com Subject: Re: [APSIMInitiative/ApsimX] Move soil water and N uptake methods out of root, into soil models (#1155)

Coming back to this after some time.

The Method below is from Root organ where soil water supply is calculated

[image]https://cloud.githubusercontent.com/assets/7295858/22901455/9ecdac48-f296-11e6-96b6-1c6fb382dce4.png

The highlighted bits are SoilWat specific. For the Multipore water more water uptake will be done differently. @hol353https://github.com/hol353 Should we put if statements into root to determine what soil water model it is dealing with and apply the appropriate calculations, or should this supply calculation be moved into the soil models. @fai04dhttps://github.com/fai04d how are you doing this for SWIM??

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/APSIMInitiative/ApsimX/issues/1155#issuecomment-279510462, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ALVK2kLr_PJZaGkyzEP5b6buBzhhxQ_cks5rcLtGgaJpZM4J4VMN.

[HamishBrownPFR]

I understand arbitrator calculates uptakes, but to do so it gets a potential uptake from the root and currently the root only calculates its potential uptake with kl, the SoilWat method. I have not put water uptake into the multipore water model yet either because of this limitation but trying to work out what the solution will be so I know how to tackle it when I need to (which will be soon). Perhaps we can spend a bit of time discussing this when @hut104 and @hol353 are over in NZ.