Critical predation efficiency must be less than 1

[agruss2]

Today, I ran a test with the bridge between FishBase/SeaLifeBase and OSMOSE. In the "osm_param-predation.csv" file, I noticed that some of the critical predation efficiencies (parameters "predation.efficiency.critical.spX") were above 1, while critical predation efficiency is a parameter that must always be less than 1. I think that this is due to the fact that: (1) critical predation efficiency = MaintQB / PopQB. (2) Jorrit added the parameter "popqb.MaintQB" to the "fishbase-mapping.csv" file and set the default value of the "popqb.MaintQB" parameter to 0.57. (3) 0.57 is the default value of critical predation efficiency. Therefore, if PopQB is less than 0.57 and MaintQB is set to its current default value of 0.57, then the critical predation efficiency calculated by the API will be greater than 1.

--> Therefore, here is what I propose: (1) We remove the "popqb.MaintQB" parameter from the "fishbase-mapping.csv" file; (2) In the API, we implement a simple rule of thumb such that: (i) if both MaintQB and PopQB are missing, critical predation efficiency is set to its default value of 0.57; (ii) if PopQB is available but MaintQB is missing, MaintQB is calculated as: PopQB times 0.57. @jhpoelen Could you please implement this? Once you are done, please let me know and I will run a new test with the bridge between FishBase/SeaLifeBase and OSMOSE to check whether the critical predation efficiencies that are provided to the user are always less than 1. Many thanks!

[jhpoelen]

Thanks for reporting this.

As far as I can tell, the desired behavior can be achieved by setting the default value of popqb.MaintQB to "NA". I've made changes accordingly and added some unit tests to verify desired behavior.

Please confirm that the functionality is working as expected.

[agruss2]

@jhpoelen Today, I ran another test with the bridge between FishBase/SeaLifeBase and OSMOSE; and, in the "osm_param-predation.csv" file, there were still some critical predation efficiencies above 1. Would it be doable to implement a rule with the API, such that, if the API notices a value for a predation.efficiency.critical.sp* parameter that is above 1, it replaces this value by 0.57? Please let know what you think.

[jhpoelen]

@agruss2 thanks for your feedback. I attempted to reproduce your observation by creating selecting ecosystem "Gulf of Mexico" and selecting the first functional group as a background group. On inspecting the osm_predation_paramters.csv , I saw that all values for parameters with prefix predation.efficiency.critical.sp in expected range [0...1] . Please see attached configuration archive.

Please provide the steps so that I can reproduce your observation.

Thanks for your patience. osmose_config_issue113_20170528.zip

[agruss2]

@jhpoelen Sorry, I should have provided more information about my observation. I did not write my previous comment after having queried parameters for the Gulf of Mexico. I wrote my previous comment after having queried parameters for the Iceland Shelf/Sea ecosystem. Here is the "osm_param-predation" config file I obtained for the Iceland Shelf/Sea ecosystem: osm_param-predation.xlsx As you can see, the critical predation efficiency of the functional group "sp3" is greater than 1 (1.60). Could you please identity the reason for this? And implement something in the API that guarantees that all of the critical predation efficiencies that are provided to the user are smaller than 1. Many thanks.

[jhpoelen]

@agruss2 I was able to reproduce using your input.

On inspect of the popqd table as extracted from fishbase api (see https://github.com/jhpoelen/fishbase_archiver/releases/download/v0.2.1/popqb_fishbase.tsv.gz) I found various rows in which MaintQB > PopQB .

For instance,

Row 76, speccode 359 http://fishbase.org/summary/359 Perca flavescens has a MaintQB of about 4.24 and a PopQB of about 2.79.

Also, on row 52 http://fishbase.org/summary/238 Salmo trutta has a MaintQB of about 18.10 and a PopQB of about 11.73.

So, this seems to suggest that either (a) data errors exist in Fishbase (perhaps a data entry error?) or (b) assumption made that predation.efficiency.critical.sp should be within [0..1] or (c) the calculation of predation.efficiency.critical.sp should be adjusted.

Please advise.

[agruss2]

@FIN-JBarile @Dengaloo Please read the comment from Jorrit above. For all the species included in FishBase and SeaLifeBase, we would like MaintQB to always be smaller than PopQB . Could you please revise your calculations of MaintQB and PopQB to make sure that MaintQB is always smaller than PopQB? Once you have come up with a solution, please let @jhpoelen and me know, so that the present issue can be fully resolved.

If you have any concerns/comments, please let @jhpoelen and me know here, so that we find a solution to the present issue.

Many thanks.

[FIN-JBarile]

@agruss2 @jhpoelen The cases you reported above are 2 of 3 records in FishBase that have MaintQB greater than PopQB. I will forward to colleagues who can make necessary corrections if indeed these are data errors.

Please note, that MaintQB is not always available for all species in FishBase and SeaLifeBase.

[jhpoelen]

Thanks for looking into this. Please let me know when changes are in and available through the fishbase api. If needed, I can implement some workaround (e.g. hardcoded values for specific values) so that we can move on before the next official fishbase release.

[FIN-JBarile]

@jhpoelen Thanks for your workaround proposal, which is okay. However, I can't give the corrected values just yet. Will give to you once I have them. In the meantime, maybe you can apply a validation for qualifying values of PopQb and MaintQB such that above case is ignored, or not fetched. Thanks.

[agruss2]

@FIN-JBarile @jhpoelen Many thanks for having interacted on this issue. Please keep me posted once changes have been made in the calculations of PopQB and MaintQB; I will then run a new test with the bridge between FishBase/SeaLifeBase and OSMOSE to see if the present issue can be closed.

[jhpoelen]

Change has been implemented as suggested. Please verify.

[agruss2]

@jhpoelen Many thanks. I just ran a new test for the Iceland Shelf/Sea ecosystem and the issue identified earlier has been solved; I can therefore close the present issue.