Soil Sat maximum

[f-avendano]

Hi everyone,

Sorry, this might sound like a basic question, but turns out I'm trying to model nitrate leaching from a potato crop, and when I try to parameterise the soil, I receive an error saying "Saturation is above the acceptable value of..., you must adjust bulk density or saturation". I guess what APSIM makes is an estimation of saturation as porosity, and for that, particle density is fixed as 2.65, but my last layer has higher particle density. I consider this important, as leaching may vary significantly depending on the saturation.

Any chances to change this?

Thank you very much!

[peter-devoil]

Here's a guide to common values. Are you confident your BD is > 2.65?

There's some more info on page 8 in the APSoil parameters protocol.

[rcichota]

I have been working with a somewhat old version of APSIM and did not realise this check has been implemented so draconian manner. I have several simulations that now do not run because of the same issue... arghh! The value of 2.65 is a general average, which means there are particles with greater density, especially those of volcanic origin like basalt (it can be as high as 3.0). Many soil show value of 2.7-2.75 in New Zealand

[rcichota]

Hi @hol353 and @hol430, I think the fact that this check is a fatal error is going to cause problems, it certainly made several of my simulations to stop working.
I was aware that the change for this checkto be an error instead of a warning. I think it was briefly discussed in our Apsim sprint in NZ earlier in the year. As I said then, the value of 2.65 for particle density is a good general average, but there is plenty of variation around. There may be a case to argue how important it is, but many users will want to put their measured values and get this error, and it will be frustrating.
I suppose one could move this check to return a simple warning, but as I mentioned before, ideally this property should be available for the user to add in the 'PhysicalProperties' node of soil. It could be filled in with the default value of 2.65, but allow to be overwritten but the user. Would that cause a lot of trouble to implement and to update existing simulations?

[hol430]

@hut104 what do you think about this one?

If BD is higher than 2.65 in some soils then this probably shouldn't be a fatal error. On the other hand, there may not be much point in making this a warning, as most users ignore warnings (and the summary file).

Perhaps warnings should appear in the status panel in the GUI after a simulation is run, and get printed to stderr when running from the command line? That would at least make them more visible.

[peter-devoil]

My apologies for not replying sooner - this issue is about particle density, not bulk density. Particle density can indeed reach 3ish (I asked), so there shouldn't be an issue "externalising" that number (eg "particle_density_max"). Given the manner these numbers come to the model, you can't have too many sanity checks.

[hut104]

Keep it fatal, but make particle density a soil parameter.

[rcichota]

I agree that fatal error is better, provided we have the capability to change the particle density. It will add overhead to the user as many times particle density is not measured. If the SAT and BD don't conform with the particle density of 2.65, less experienced users will be scratching their heads. A good error message should be sufficient to get around this.

[rcichota]

I was checking some data for stony yesterday (good timing for this discussion...). I realised that firstly there is no field to enter stone content in the GUI, but more importantly the way we have been dealing with parameters for stony soil will result in fatal error because of the particle density issue.
The approach we have been taking for stony soils is to correct a priori the measured values (BD, SAT, DUL and LLs), which generally refer to only the fine fraction. This is done by:
BD(Apsim) = BD(measured) * (1 - FractionStones)
SAT(Apsim) = SAT(measured) * (1 - FractionStones)
When you do this, even if the values were in conformity to a particle density of 2.65 originally, the corrected values will not, in fact they will be way out. Give you an example:
If a soil has a BD of 1.325, the theoretical value of SAT with particle density of 2.65 will be 0.5. If the soil has 50% of stones, we would enter BD as 0.6625 and SAT = 0.25. But if still using the same particle denstiy, SAT would be 0.75...

[rcichota]

I think it would be good to have a column to enter stone content. At least to keep record of how the soil really is (and easily understand why some values of BD, for example, are wacky). My guess this was removed because having these values in the GUI but not actually using may cause confusion (the user may infer it is important, or worse assume that the values will used to adjust the physical properties and enter wrong values in there). This is true, but not having anything there is confusing too.
Should we be considering having stones in the GUI and let Apsim do the adjustments? Should we be telling the user about which value should be entered when dealing with stony soils?

[hut104]

I think the answer is yes, the problem will be in how we convert all the numbers over. We have soil parameter sets that would include stones in some of the caluclations (e.g. DUL) but not in other data (eg. no3ppm). We would probably be more accurate with things, we'd need to be clear which have been configured with/without considering the rocks. A good job for someone...

…

________________________________ From: Rogerio Cichota <notifications@github.com> Sent: Friday, 29 May 2020 9:40 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] Soil Sat maximum (#5130) I think it would be good to have a column to enter stone content. At least to keep record of how the soil really is (and easily understand why some values of BD, for example, are wacky). My guess this was removed because having these values in the GUI but not actually using may cause confusion (the user may infer it is important, or worse assume that the values will used to adjust the physical properties and enter wrong values in there). This is true, but not having anything there is confusing too. Should we be considering having stones in the GUI and let Apsim do the adjustments? Should we be telling the user about which value should be entered when dealing with stony soils? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#5130 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AC2UVWUS4XKG4SHQBNBB5ELRT3Y6LANCNFSM4M37RYOQ>.

[hut104]

I think you'll find that most of our soils have the measured DUL including the stones if stones are small.

…

________________________________ From: Rogerio Cichota <notifications@github.com> Sent: Friday, 29 May 2020 9:31 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] Soil Sat maximum (#5130) I was checking some data for stony yesterday (good timing for this discussion...). I realised that firstly there is no field to enter stone content in the GUI, but more importantly the way we have been dealing with parameters for stony soil will result in fatal error because of the particle density issue. The approach we have been taking for stony soils is to correct a priori the measured values (BD, SAT, DUL and LLs), which generally refer to only the fine fraction. This is done by: BD(Apsim) = BD(measured) * (1 - FractionStones) SAT(Apsim) = SAT(measured) * (1 - FractionStones) When you do this, even if the values were in conformity to a particle density of 2.65 originally, the corrected values will not, in fact they will be way out. Give you an example: If a soil has a BD of 1.325, the theoretical value of SAT with particle density of 2.65 will be 0.5. If the soil has 50% of stones, we would enter BD as 0.6625 and SAT = 0.25. But if still using the same particle denstiy, SAT would be 0.75... — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#5130 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AC2UVWXHU4ICJ3LZVVPJX4LRT3X4BANCNFSM4M37RYOQ>.

[rcichota]

I agree with you Neil. It may not be a small job, but then maybe it is not too bad, if we can compromise. For instance, now all parameters are assumed to be stone-corrected, and if the stone column has been removed already, I assume any information we had about that has been lost (?). If it is so, we could put stone content back and simply assume its value is zero. Of course, things like conversion from older versions where the information is still there would be a bit more tricky.
As far as I am aware, only the physical properties, and not even all, need to be adjusted. Values of no3ppm of OC% are already generally measured on the fine-earth fraction... There might be some variations for country or even lab. But in any case currently the user does not know which value is best to enter. So we should make this clearer in the GUI, but before we should define which approach is best / easier...
It is a good job for some alright, lets see if we can get some time after of financial year in July...
Though sometimes they may not

[rcichota]

I think you'll find that most of our soils have the measured DUL including the stones if stones are small.
…

Field derived measurements are an issue indeed. Small stone content or a considerable amount of small stones may be ignored (or whole soil samples may be used) even for some lab measurements. Not sure what is the best way to deal with those. It seem we have a too short blanked :)

[sno036]

I think we need to bite the bullet and make stones (entering 0 if none and maybe have this as a default) and particle density (happy with 2.65 as a default) mandatory. SoilTemperature will need to calculate bulk density including stones (because the stones conduct heat) - I will look up some sort of default density for the bulk density of the stone content.

[stale]

This issue has been automatically marked as stale because it has not had any activity in the last 30 days. It will be closed in one week if no further activity occurs. Thank you for your contributions.

[hol430]

Stale but not solved.

[frank0434]

I think I run into this wall now.

System.Exception: Saturation of 0.403 in layer 20 is above acceptable value of 0.400. You must adjust bulk density to below 1.582 OR saturation to below 0.400

I have the saturation value derived from field TDR measurements as the maximum value across the experiment period.
Layer20 was 2.1 m depth.
wondering should I change the bulk density or should I reduce the saturation? or maybe I need to modify the value 2.65?

@hut104 @rcichota

Thank you in advance for any tip.

[rcichota]

If both saturation and bulk density were measured then ideally you would change the value of particle density. However, this is not trivial, as it is hard coded (and we have only one value for the whole soil).
Pragmatically, I'd suggest modifying the value of bulk density if you are interested in simulating water, or change saturation if focusing on N and/or C...

[frank0434]

If both saturation and bulk density were measured then ideally you would change the value of particle density. However, this is not trivial, as it is hard coded (and we have only one value for the whole soil).
Pragmatically, I'd suggest modifying the value of bulk density if you are interested in simulating water, or change saturation if focusing on N and/or C...

thanks very much, Rogerio. Changed bulk density is the way then.