I am still getting an error Error in format_weather(x = Billa_Billa, POSIXct_time = "local_time", : 'POSIXct_time' is not class POSIXct

This should have been fixed via 32df19d ?

If I'm interpreting it right, current_growing_points have been made equivalent to gp_standard, which is not correct because as definition gp_standard refer to uninfective_gp (standard growing points assuming growth is not impeded by infection)
Indeed, current_growing_points are the total number of growing points at an iteration period (both healthy + infected)

Should calc_new_gp return an error in the following tests?

# Test function if current growing points is zero
test1 <- calc_new_gp(
  current_growing_points = 0,
  gp_rr = 0.0065,
  max_gp = 15000,
  mean_air_temp = 24
)

# Test function if current growing points is a negative
test2 <- calc_new_gp(
  current_growing_points = -1,
  gp_rr = 0.0065,
  max_gp = 15000,
  mean_air_temp = 24
)

Currently the model is geared to accept the primary_infection_foci as one coordinate.

We should make sure there is functionality to accept a data.frame or list of coordinates.

Does 0.1 mm in one hour constitute a wet hour? or is the cut off higher?

Could you please merge master branch with one_day branch as we discussed yesterday? I want to make some more edits

The function only takes current_growing_points and mean_air_temp but inside the function, the object, growing_points_replication_rate is called but not passed into the function nor created within the function.

@PaulMelloy I was talking about this graph listed in this paper https://www.ncbi.nlm.nih.gov/pmc/articles/PMC8000037/pdf/plants-10-00464.pdf

We can just compare disease progress curve over time and not worry about distance. Tha is, months on x-axis and disease progress on y-axis. In addition, we can include growing points dynamics graph and submit it to Mycological Progress or MDPI journal. I can play with the words

I used the same approach in one of my papers from PhD. I just compared sporangia production curves, and did not do any statistics https://link.springer.com/article/10.1007/s11557-020-01578-4

Summary unit length and width is 1 square metre, so everything gets divided by one and give some strange numbers

This is the description of the function The intensity of the starting epidemic as described by the number of number of sporulating growing points.
This is the function
if (primary_infection_intensity > seeding_rate) {
stop(
"primary_infection_intensity exceeds the number of starting growing points - 'seeding_rate': ",
seeding_rate
)
}

Reasons why it's invalid

1. The function is saying conidia splash from primary foci (stubble), then cause primary infection. Intensity refers to how many lesions resulting from that primary spread, so lesions can be greater than seeding rate

2. If I increase or decrease the value, it doesn't have much effect on the disease spread

3. The major problem is the way the model is interpreting it. It the value is 100, then the model can produce a total of 100 lesions over the duration of the experiment

It the value is 1000, then the model can produce a total of 1000 lesions over the duration of the experiment

3. When the function is temporarily removed, the model can produce only 4 lesions per quadrat over the duration of the experiment
   

As discussed previously this model has nothing to do with the duration of rainfall. It only considers rain amount, not duration, so i_wet_hours =2 should not be specified. I have changed the value to select rows where rain was more than zero on the chickpea branch and I seem to be getting sporulating_gp.

I am wondering if we need to have all the following functions nested within the function spread_spores. It might be easier to code it all into fewer nestings and cut down on passing parameters from the top function to the bottom function.

Nesting as follows
trace_asco
-> one_day
->-> spread_spores
->->-> interception_probability
->->-> spores_each_wet_hour
->->->-> spores_from_1_element
->->->->-> potentially_effective_spores
->->->->-> wind_distance
->->->->-> splash_distance
->->->->-> splash_angle
->->->->-> address_from_center_distance
->->->->-> adjust_for_interception
->->->->->-> successful_infections
->->->->->->-> interception_probability
->->->->->->-> random_integer_from_real

each "->" indicates how many functions the named function is nested in
TBC....

As discussed in issue #71

I've been away from pure R programming for over 3 months, so please bear with me.

First, the package won't load using devetools::load_all() getting this error Error during wrapup: Supplied column names are not found in column names of x Error: no more error handlers available (recursive errors?); invoking 'abort' restart AND directs me to row 228–230 in format_weather function

if(all(c(temp, rain, ws, wd, wd_sd, station) %in% colnames(x)) == FALSE){
stop("Supplied column names are not found in column names of x")
}

Second, I have tried 'install and rebuildbut that won't work either. Getting this errorExited with status 1.`

Third, I can't import Billa Billa weather data either via this commit ac28ee8
I've created a new branch chickpea, so working on this branch

Not sure what's happening?

The calc_new_gp function needs to be checked in Mathematica code and literature that it is supposed to return a floating-point number.
I think it would make more sense if it returned an integer.

I am considering wrapping the output in the random_integer_from_real() function

To be decided in the fortnightly meeting. No comments required

I think it would be much cleaner model and code if all variables relating to each paddock coordinate is contained and updated within a paddock data.table.

This is somewhat different to the Mathematica code which stores paddock values in a number of different lists with strikingly similar names i.e. (paddockUninfectiveGrowingPoints, paddockInfectiveGrowingPoints, paddockNewGrowingPoints, newlyInfectedList, infectiveElementsList, ... and others)

issues related to this are #45 #46 and #47

Travis-CI is not going to be a viable option going forward, see this article:
https://ropensci.org/technotes/2020/11/19/moving-away-travis/

{tic} makes it very easy to set up and maintain CI and GitHub actions, https://docs.ropensci.org/tic/.

However, as this repository is private, you'll quickly run into issues using your allocated time for builds. Therefore, I suggest you wait until the repository is made public before using CI. In the meantime, you already have access to Windows and macOS to easily test and can install a VM if you need Linux.

The date of first infection commences with the first day of the model, sowing_date.
Where it should commence on initial_infection day but it doesn't
This needs to be fixed

@PaulMelloy format_weather can't runlon_lat file taking me to the following function.

The problem doesn't go away even if hash out the function or even remove it temporarily. Both weather data and lon_lat data can be imported/viewed, but it can't be passed through format_weather function due to this error. The package is loading/rebuilding a, so I'm not sure where is the problem

@PaulMelloy just checking if per_area is dropped from maximum growing points, or it has been missed? The original code in Mathematica and our maximum growing points function in R has per_area with it
Original code
max_growing_points <- function(){
per_area(max_growing_points_limit * (1 - exp(-0.138629 * min_growing_points)))
}

https://github.com/IhsanKhaliq/Ascotracer/blob/8606002c204421199496a96e28793e49ea19636d/R/trace_asco.R#L136-L137

I've been looking for the function that calculates the number of uninfected growing points to paste it in the manuscript. It's equation-2 in Art paper, but I can't find the function for it in either mathematica or R scripts. Just update_ref_uninfective_gp is given, but the equation is different than that given in the Art Paper. Also, a note has been made that the update_ref_uninfective_gp function to calculate healthy growing points is replaced by calc_new_gp , which does not seem a good idea because both are different. Have we given it a different name? I've highlighted this in the comment manuscript too

https://github.com/IhsanKhaliq/Ascotracer/blob/087e9d485b495bdf49f0a611277c4dfbbdb62aa6/R/trace_asco.R#L153

There is no gp_standard in the original model, and its value (40) has already been assigned to the min_gp'. P.s. If minimum growing points per day are 350 and maximum growing points per square metre are 15000, then 40 doesn't seem the right value for gp_standard`

We can discuss on Monday but @param min_new_gp_for_half_limit is not required. There is a comment is anthracnosetracer model not being used now and it's not being used any function in the script. I can't reference the exact lines in the issue because one_day function doesn't have any content here on github. Has one_day function been pushed to GitHub?

@PaulMelloy I wanted to verify the value of spore_interception_multiplier = 0.0006, so I went to back to the original model script. Not only I could not find any term spore_interception_multiplier' but I could not find this whole function. Upon closer look, I realised that a mistake was made in the function translation. That is 'spore_interception_parameter has been called spore_interception_multiplier. Please see screenshot of the mathematica code.

https://github.com/IhsanKhaliq/Ascotracer/blob/30b803097f215546d35016ba45772949304de46d/R/intercept_spores.R#L14-L19

Non_infected_gp, infected_gp and new_gp are not getting updated much as the season progresses (only in fractions). There are no infected_gp at all. The non_infected_gp value is 14938 (value is changing in fractions) from the begging to the end, and new_gp value is 0.50 (value is changing in fractions) from the begging to the end.

Growing points per quadrat values should start from lower values and gradually increase until maximum 15000 per quadrat. In a very few quadrats (when value changes from 0.50 to 1), when total growing points are added, the total value exceeds 15000, which is the upper limit on the number of growing points per quadrat.

Not sure why the update of infected_coords has been made dependent on the presence of sporulating_gp. Only infected_gp need to be present for infected_coords to get updated

Need some thinking on the issues. Farmers can put the location of stubble as random, but they would never know the number of infested stubble that will initiate infections. This message/option `stop("primary_infection_foci should be supplied as a numeric vector of length two. probably need deleting because if the location of stubble is random then it is not required anyway. Ps farmers would never be able to put the coordinates (they would remove the stubble rather than putting the coordinates in the model)

Following R naming conventions, this should be ascotraceR, no? 😀

I bumped into Kevin Moore today, bailed him up with a few questions.

One thing he mentioned was in an experiment the latent period was about 5-7 days, depending on host genotype, in glasshouse experiments with day night temperatures of 20 and 15 C.
This implies a cumulative degree day latent period of between 122.5 - 87.5, which is less than the 200 set in the model.
This is a parameter we might consider changing for the ascotraceR chickpea model

Just want to document and discuss dropping the function wrap_address.

I can't see the use for this function in spore dispersal models ever. Correct me if I am wrong, but the function seems to: if an infection coordinate is generated outside the paddock dimensions to takes the x or y coordinate and moderates it. for example

If the paddock dimensions are 100m x 100m and the grid is 1x1m
and a coordinate is generated of c(50,105) the function "wraps" this address so the output is c(50,5)

I am in favour of if a coordinate is generated which is outside the study area the coordinates are dropped. Therefore I suggest removing this function.

I came across this filter for a rainfall threshold at 0.2mm in 1 hour
bd8aa28

I just want to check is this rainfall correct?
I had a quick looked in the Mathematica code and could not find a rainfall threshold.
If we do want to place a rainfall threshold, is this a parameter we want to put in the main function so the user can alter it?

I am sceptical if the interception_probability function is correctly written.

More tests need to be written with realistic input values to determine if it will return a number other than 1 under realistic scenarios.

See commit a85694e

@PaulMelloy When I run the function format weather, it runs but stops at line 264 at function about missing temperature column. But the temp column is not missing in the data.

I have added temp argument in the function signature too.

But it still stops at line 264

The simple function interception_probability needs some tests written for it.

I have tried to figure out how to load the data.table on loading ascotracer but my efforts have failed. Also the internet seems to suggest that having another package as a dependency is not a good idea. I understand this for packages that are not called often, however this is what we have done in blackspot.

Adam can you add data.table so it loads when ascotracer loads and describe how to do it with best practice please?

The model code would be easier to follow if we rename names to
Susceptible_gp
exposed_gp
infections_gp
removed_gp

For internal record & reference

I propose dropping the growth function and replacing to with two functions.

1. A function which updates the non-infected growing points
2. A function which updates the infected growing points

The reason for this is that a function should always return an output and not update objects in the environment. Unlike the Mathematica code which allows objects to be changed in a function without producing an output

Discussed in meeting,
The amount of rainfall in a rain hour/event effects the potentially_effective_spores. However, this is not included in the model.

We could easily add this as a multiplier, we need coefficients from models to base this multiplier off.

@IhsanKhaliq could you provide references that report coefficients for rain quantity impacting spore dispersal

These are just notes to assist in understanding the model workflow, no comments needed.

infectPlantsAt = list / data.frame of coordinates

• which is parsed through packetsFromLocations (which just wraps coordinates into the first element if a list, and adds a 1 to the second element )
  additionalNewlyInfectiveList <- infectPlantsAt i.e. list(c("x","y"),1)

Then additionalNewlyInfectiveList is used in function makeSomeInfective() and never used again.

makeSomeInfective

• A sporePacket refers to additionalNewlyInfectiveList mentioned above.
• sporesInPacket is numeric and 1 on the first run
• paddockUninfectiveGrowingPoints a data.table for each 1x1m unit all containing the values -1 at the start.
  (a) coords with values less than -0.5 are added to infectiveElementsList (for coords from additionalNewlyInfectiveList) ; then
  (b) paddockUninfectiveGrowingPoints (for coords from additionalNewlyInfectiveList) are updated with refUninfectiveGrowingPoints (40 the seeding_rate)
  (c) (i) infectionsNew <- paddockUninfectiveGrowingPoints which are then less than sporesInPacket (1 as allocated in packetsFromLocations)(none on first run with coords from additionalNewlyInfectiveList) ) and
  (ii) update that paddockUninfectiveGrowingPoints value <- 0
  (d) (i) infectionsNew <- sporesInPacket (1) when paddockUninfectiveGrowingPoints is equal or greater than sporesInPacket ( additionalNewlyInfectiveList coords on first run) and
  (ii) update paddockUninfectiveGrowingPoints value <- paddockUninfectiveGrowingPoints - infectionsNew (first run: 40 - 1)
• finally paddockInfectiveGrowingPoints (note: Infective not uninfective) <- paddockInfectiveGrowingPoints + infectionsNew (first run: 0 + 1)

Therefore on the first run the function makes the following changes to global environment variables

• infectiveElementsList contains coords from additionalNewlyInfectiveList)
• paddockUninfectiveGrowingPoints at coords from additionalNewlyInfectiveList contain value 40
• paddock__Infective__GrowingPoints at coords is updated to contain value 1

To be discussed in the fortnightly meeting. No comments required

https://github.com/IhsanKhaliq/Ascotracer/blob/d241125729ce383ec56f3a9ff8b69f3deb3789c4/R/trace_asco.R#L48-L61

Table 3 of Art paper lists parameters used in the model. When I look at the tras_asco function it has the following parameters missing
Distance due to rain splash
Distance due to wind
Spore deposition
Rainfall threshold
Potentially infective spore pro
The duration for which when a new growing point is susceptible
Base temperature for spore growth

There are many additional parameters in trace_asco function, but I guess there is nothing wrong with the additional parameters. But we should add missing parameters.
I can add them if you like.

Paul, in tras_asco function signature Line 56, the spore_interception_multiplier value is 0.00006. In the anthracnosetracer model it is called sporeInterceptionParameter and its value is 0.00006 maxGrowingPointsLimit /maxNewGrowingPointsLimit . So we need to change the name and value?

This is the definition (* the parameter which controls the relationship between uninfective \ growing points per area and probability of a spore causing an \ infection *)

https://github.com/IhsanKhaliq/Ascotracer/blob/d241125729ce383ec56f3a9ff8b69f3deb3789c4/R/trace_asco.R#L109-L110

Not sure why are new_gp and noninfected_gp assigned to seeding_rate. They have their own function to calculate these

The format_weather function has been pulled in from the PaulMelloy/blackspot package. Originally temperature did not feature as an argument for the function. Temperature is needed in Ascotracer and this argument is added.
However Ascotracer uses daily mean temperatures to calculate degree days and inform the maturation of the crop and spores.
We may need to provide an option to specify columns:

• daily_mean_temp for mean daily temperature
• temp for mean temperature for the aggregated row time unit.

When the primary_infection_intensity is 1000. I get below output in CSV and `tracer_plot

As you can see, there are a lot more sporulating_gp/spread in CSV file than shown in the `tracer_plot

In contrast, when primary_infection_intensity is 2. I get below output in CSV and `tracer_plot

We are getting a lot more spread when primary_infection_intensity is 2 than 1000. Not only it doesn't match CSV, but also it should be the other way around. That is, more spread should be observed when primary_infection_intensity is 1000 in tracer_plot