CalculationMode inside nested repeat

1146
7
03-14-2022 02:09 AM
Mondi_GIS
Occasional Contributor

Good day,

I am trying to run a calculation with uses the calculationMode=always feature. Basically, we are collection measured  tree heights and then for each tree inside the repeat, we determine whether it is inside or outside of a specified range (20% above or below the mean). The mean obviously recalculates with each entry that is added. The mean recalculates fine, but the behaviour I am seeing is that the values inside the repeat only recalculate when I read the repeat. 

So basically, the out of range and within range boolean values only update if I actually go to that repeat and look at it. This would be a huge nuisance and leave a lot of room for error in the assessment. I have tried to reference the top_from_mean and lower_from_mean inside the repeat, but they also do not recalculate until you scroll back to that record in the repeat:

Here is an extract from Survey123 connect showing have the top and lower from mean values have not recalcuated: 

{
"Stocking_assessment_test": {
"Plot_repeat": [
{
"plotno_calc": 1,
"plotno2": 1,
"count_trees": 3,
"count_trees_alive": 3,
"avg_height_alive": 53.33,
"survival_pits": 100,
"top_from_mean": 64,
"lower_from_mean": 42.66,
"notacceptable": 0,
"acceptable": 3,
"uniformity_calc": 100,
"trees": [
{
"treeno_calc": 1,
"treeno": 1,
"height": 54,
"alive": 1,
"out_of_range": 0,
"within_range": 1,
"top_from_mean_2": 64.8,
"lower_from_mean_2": 43.2,
"plant_status": "alive"
},
{
"treeno_calc": 1,
"treeno": 2,
"height": 63,
"alive": 1,
"out_of_range": 0,
"within_range": 1,
"top_from_mean_2": 70.2,
"lower_from_mean_2": 46.8,
"plant_status": "alive"
},
{
"treeno_calc": 1,
"treeno": 3,
"height": 43,
"alive": 1,
"out_of_range": 0,
"within_range": 1,
"top_from_mean_2": 64,
"lower_from_mean_2": 42.66,
"plant_status": "alive"
}
]
}
],
"wpu_list": "BABANANGO"
}
}

0 Kudos
7 Replies
by Anonymous User
Not applicable

Hi @Mondi_GIS,

This is expected. For calculations to run in a repeat or nested repeat set of records, the actual repeat record needs to be navigated to and visible, for the form to evaluate and run the expressions for that record. This has always been the case with Survey123 forms, and using calculationModes does not change this.

Regards,

Phil.

0 Kudos
Mondi_GIS
Occasional Contributor

Hi Philip,

Surely that defeats the benefits of having the calculation mode then? The only alternative I can think of is to create fields referencing indexed-repeat values, and for that I will have to have 70 fields referencing the trees, and outside of that, 40 fields referencing the plots, instead of it just being able to calculate within the repeat. 

Would it not make more sense to have the option (as with the calculation mode) to decide whether to optimize for all the unnecessary additional fields, or for the refresh within a repeat without revisiting the repeat? 

It's really disappointing that there is such a major limitation with Survey123 in this regard. I can't see how it is better performance wise to have to calculate the index and then evaluation the expression and have a "Sum" which now references 70 fields instead of summing up a single field in a repeat. 

by Anonymous User
Not applicable

Hi @Mondi_GIS,

Totally understand your disappointment with this, but unfortunately that is the current implementation with repeats in Survey123. We have a few enhancements to consider in the future, which would resolve this limitation, however it requires significant development work as to how repeats are implemented. Something we plan to address in a future release, but not on current near term roadmap.

Regards,

Phil.

0 Kudos
DougBrowning
MVP Esteemed Contributor

I just hit this with repeats today. Thought it would be a great fix, bummer.  Would be super handy.  That or validation by page.  Really a required is not much use if it does not fire until the very end.

We have an issue where the crew needs to pick a line number of page 1 and then that number gets calced into each repeat.  But if they miss the line number on page 1 all 50 repeats get no line number and become orphans.  We spend hours and hours on QA to fix all of these which gets expensive.

We also cannot hide page 2 since it gets too big for memory and the iPad crashes.  Would hidden use less memory?  It is hard to test since our new iPads can make it but the older ones no.

Open to any other ideas.  thanks

Mondi_GIS
Occasional Contributor

I find it strange to be focusing on smart cameras and all sorts of fanciness but basic calculations don't work... 

 

Anyhow, in my attempts to create my 70X40 matrix of calculations to overcome the shortcomings of our favorite tool, I'm running into an issue with the indexed repeat (which may just be some faulty syntax here...) I get this error -21- in the field as soon as I enter a value into the repeats:

 

Mondi_GIS_0-1648137468783.png

The syntax I am using in the calculation is

 

if((indexed-repeat(${height},${Plot_repeat},2))>(int(${top_from_mean_plot})),1,if((indexed-repeat(${height},${Plot_repeat},2))<(int(${lower_from_mean_plot})),1,0))

I have split out the two if statements and they both behave as expectedly individually when I have them as separate questions, but when combined, they just don't work properly! (By the way, is the error message service for Survey123 broken at present?). I have tried having the calcs within brackets, or outside of brackets and tried with the values 1 and 0 in as '1' and '0' but it doesn't  make a difference! Am I missing something obvious?

ZacharySutherby
Esri Regular Contributor

Hello @Mondi_GIS

Assuming your form is still similar to the one linked above, you would want to use the trees repeat and not the Plot_repeat. I would suggest either storing the indexed-repeat calculation in it's own question and referencing that in the if statement, or combining the two conditions to be something like: 

if(indexed-repeat(${height},${trees},2)>${top_from_mean_2} or indexed-repeat(${height},${trees},2)<${lower_from_mean_2},1,0)

Thank you,
Zach
Mondi_GIS
Occasional Contributor

Hi Zachary,

Sorry, I had changed the form around a bit to simplify it for testing that calc, but the "or" option works a charm! 🙂 Thank you!