What order are custom fields calculated in the Empower database?
Options
I know that summary custom fields that depend on each other must be alphabetically named to kick in correctly, so a CF like SAME.%..AVE(Area)*CConst1 may be called Z and if you then want an average of Z such as: SAME.%..AVE(Z) and call that CF something like A, then it wont work because A is before Z and no result for Z has been stored yet so the naming would have to be reversed to work.
But are all non-summary custom fields like GTE(Area,CConst1), Height*100, A.%.(Retention Time)*CConst6 etc calculated together when you process a channel and the naming doesn't matter? Does the naming only matter when you are calculating a summary CF, and you must ensure that these summary custom fields are named higher than the CF they are calculating?
What about Peak, Enum calculations, are they calculated AFTER the individual custom fields have been calculated? I will give an example: you have two custom fields called Carryover (GT(ROUND(CCompRef1[Area],0),100) and Relative_Area (Area*CConst1) and your peak enum conditions are ENUM(LT(Carryover,100)&(GTE(Relative_Area,10000)),(GTE(Carryover,100)&(GTE(Relative_Area,10000)),(GTE(Carryover,100)&(LT(Relative_Area,10000))). In this case you call this peak enum CF simply A.
Will this still function as coded or will it bomb out because values for Carryover and Relative_Area haven't been calculated yet?
But are all non-summary custom fields like GTE(Area,CConst1), Height*100, A.%.(Retention Time)*CConst6 etc calculated together when you process a channel and the naming doesn't matter? Does the naming only matter when you are calculating a summary CF, and you must ensure that these summary custom fields are named higher than the CF they are calculating?
What about Peak, Enum calculations, are they calculated AFTER the individual custom fields have been calculated? I will give an example: you have two custom fields called Carryover (GT(ROUND(CCompRef1[Area],0),100) and Relative_Area (Area*CConst1) and your peak enum conditions are ENUM(LT(Carryover,100)&(GTE(Relative_Area,10000)),(GTE(Carryover,100)&(GTE(Relative_Area,10000)),(GTE(Carryover,100)&(LT(Relative_Area,10000))). In this case you call this peak enum CF simply A.
Will this still function as coded or will it bomb out because values for Carryover and Relative_Area haven't been calculated yet?
0
Best Answer
-
I have Peak/ENUM fields (use as field type) working both in alphabetical order and in reverse for some intersample calculations. You should obviously just test it out, but I would imagine that as long as you put a "summarize sample sets" instruction in the sample set, you should be fine. Or, just to be safe, call them something different perhaps like 0001_Carryover, 0002_Relative_Area, and the ENUM 0003_X?
My cases:
Bracket agreements-I have fields for brackets comparing area to the previous labeled bracket std, then an ENUM field calling out which one to "report" based on the labels where it is alphabetical (BP01, BP02,...with an ENUM field named BP_All)
I then have an RT comparison for samples to the surrounding brackets. I have "RT_ID_All" as the ENUM field and RT_ID_B01, RT_ID_B02...etc. for the subsequent bracket comparisons0
Answers
-
Thanks MJS, yes I have had problems with CFs, even non summary ones which didn't quite give the correct answer until I named them alphabetically as I required them, so Average_Amount, then B_AverageAmount_Factor etc, its now something ill always try to do when possible to prevent any issues during routine use.0