Extra columns for `format_weather` function about ascotracer HOT 15 CLOSED

Asking again. Why is this pulled in rather than in a separate package as I have specified needs to be done?

I realise that there are some minor differences here but the majority of the weather formating is the same between models. I'm envisioning a suite of R packages that use the same format of weather data give or take a column here and there. Maintaining code across several packages vs just one is not optimal.

from ascotracer.

Yes that is the goal, to build a suite of functions in a phytopath_tools or epiphytopath_tools package.

We have yet to initialise this package. I guess there is no time like the present.

The reason for bringing this issue up was to make aware that the format_weather function needs to be more flexible to work with packages other than the blackspot package. And the need to improve the development of this function so it is flexible between blackspot, Ascotracer and future packages.

Ascotracer requires weather data, but not in the same format as blackspot.

I think as I get further into the development of Ascotracer I will have a better grasp on how I can alter Ascotracer to accept more generically formatted weather data. And also add enhancements to format_weather to provide that S3 generic format.

from ascotracer.

I was thinking about the class of the object, we could call it a "sporacle" class after Moin's original model.

If the models themselves need something special, we can handle minor formatting, selecting cols or whatnot in them but most of the weather formatting and checking should be handled with the new

Set up a package repository for the weather handling and let's see what it needs to work across these. Since we're working with weather and wind dispersal, what about calling it "Anemoi"?

from ascotracer.

To add to this issue,
I am assuming that at this stage Ascotracer will not be using lat and lon coordinates. Thus format weather should have an option to provide NA to the lat and lon arguments.

As far as I can tell Ascotracer will not, and probably should not accept weather data from more than one weather station input. Unchanged a user can add any lat and on coordinates to the weather data and they will not be used any further if they plan to use Ascotracer.

Alternativley we could add an option to the format_weather function to return an output suitable for the model input, and not provide warnings if arguments superfluous to the requirements of `Ascotracer.
eg.

method = "Ascotracer"

However I think it would be better to allow flexibility in the inputs. Then add a check in the Ascotracer model that the formatted weather contains the correct variables for the model.

from ascotracer.

from ascotracer.

I like the name anemoi however I get the feeling we will soon also be working with weather driving spore maturation as well. Something more generic might be better

from ascotracer.

Pythia?

from ascotracer.

Mean daily temperature inform crop maturity only. There is no pseudothecial maturation in case of chickpea. Conidia are produced and released in hours, not days, so degrees days are not required for conidia maturity

from ascotracer.

Yes, I should have been more specific.
Temperature is needed for the pseudothecial maturity model in blackspot

Pythia seems a bit to close to Pythium for me. Given it will probably be a package that does not get published and is a package for generic modelling tools I am happy with a generic mundane name.

from ascotracer.

Pythia was the name of one of the oracles of Delphi. Given that the original model is “sporacle”, I think it makes sense and would be related to Pythium as it’s the root word for “rot”. I think it makes perfect sense.

from ascotracer.

My hesitation from following on the use of sporacle is that while it is a witty reference and play on words. There has been discussion from Jean and Art suggesting that the name was not good for being 'searchable' or 'memorable' as a software name.
I guess what I am trying to say is what is the goal are we aiming for in the choice of name.
a) Something witty that entertains us as developers, but is less understood or 'searchable' by the wider community. Or
b) a name that is 'searchable', memorable and literal to the functions the package will serve.
It the answer is the first a), then pythia is a fantastic choice and we should go with it; however if the answer is the second IMO I think we might need to consider other ideas.

from ascotracer.

from ascotracer.

I think we're overthinking this. It's basically wrangling weather data. Something like tidyweather or weathrangler or anything along those lines works fine.

from ascotracer.

from ascotracer.

Closing because we decided not to release a separate package for formatting weather data. Only format_weather() function is used

from ascotracer.