MKLau
commented
10 years ago Qianqian Ma,
Interesting questions; thank you for posing them. I appreciate that you are looking carefully at the enaR software. Your question forced me to spend a bit of time this afternoon re-verifying that what we are doing is correct.
First, I went back to look at the article you reference and it does look like in this article Dr. Ulanowicz defines T with just the internal flows. However, in many of the articles/books I have read by him, he defines T as an (n+3)x(n+3) matrix in which he adds the respiration and export outputs as two columns beyond n and a final n+3 row for boundary inputs. If you notice in the summations in for AMI and using the engineering dot notation for sums - the full length of the index is not specified. However, in previous publications T.. implied the total system throughPUT (as opposed to the total system throughFLOW). Total system throughPUT is the sum of flows in T -- when it includes the boundary inputs and outputs. Thus, at steady state Total System ThroughPUT is greater than Total System ThroughFLOW by one additional sum of the boundary fluxes. The hint here is that in the AMI equation on page 333, the summations are over the "extended flow matrix, T". See the 2012 article by Fath in Ecological Modelling that highlights this difference between TSTf and TSTp. I suspect that this hidden difference has been the source of many errors in the literature.
In enaR, following the Patten School of ENA the flow matrix F contains only the internal flows. We do create the (n+3)x(n+3) matrix of throughflows using the as.extended() function when we are calculating ascendency and related measures. I initially did this in my matlab coding because it was so much easier to translate into the Ulanowicz form and code the equations from that perspective; I find it challenging to work back and forth between the two Schools of representations. Dave used the same approach for the enaR function. At this point I am fairly certain that our calculations are correct.
Second, to triple check that the calculations were correct, I then re-checked to make sure that the results returned by the enaR enaAscendency function matched the output from Dr. Ulanowicz's NETWRK function. For both the cone springs model and the crystal river (control) models I was able to generate the same ascendency and capacity results. Given this match, I suggest that we have NOT changed the definition of ascendancy as you assert in your email.
There is an interesting discussion in the literature about different ways of calculating the ascendency measures -- whether to calculate the total ascendancy or only the internal ascendency (using only internal flows). While we did not document this well, our calculation of ascendancy and such produces the total ascendency/overhead/capacity, which includes the boundary flows. We have not calculated the internal information indices, but because of this exchange we will modify the enaAscendnecy function to do these calculations in the near future. Given that our use of ENA is often to characterize the system with respect to its environment, I do think it makes sense to include the boundary fluxes in the calculations -- especially when our goal is to investigate a real empirical system. My reasoning for this follows the logic for using what we called the "realized" indirect-to-direct flow ratio in Borrett & Freeze (2011).
I also made another discovery in this process. The Information indices for the Cone Springs model published in Kay et al. (1989) do not match the output of NETWRK 4.2 today. I verified that the initial model was the same. Further, the Ascendency value for the Cone Springs model published in Ulanowicz (1986, p. 106) matches that of Kay et al., but not the current software output. Honestly, I am not sure what is happening here, but no wonder we are all confused!
Given that the two softwares generate the same result and I believe we are using the same equations, I will tentatively assert that the enaR calculations are correct. I wonder, do they match the output of EcoNet's calculation of the information indices? Is this what generated your question?
Again, I really appreciate your question because my goal is for the enaR software to be both useful and accurate.
Respectfully,
Stuart
REFERENCES
Borrett, Freeze (2011) Reconnecting environs to their environment. Ecological Modelling 222, 2393-2403.
Kay, Grahm, Ulanowicz (1989) "A detailed guide to network analysis" In Wulff, Field, Mann (eds) "Network Analysis in Marine Ecology" Springer-Verlag
Ulanowicz (1986) "Growth and Development: Ecosystem Phenomenology". toExcel.
Stuart Borrett Associate Professor Systems Ecology and Ecoinformatics Laboratory Dept. of Biology and Marine Biology University of North Carolina Wilmington http://people.uncw.edu/borretts/
http://uncw.academia.edu/StuartBorrett
https://www.researchgate.net/profile/Stuart_Borrett/
"A system is never the sum of its parts, it's the product of their interactions" Russell Ackoff (http://bit.ly/gpu6d2)
On Oct 15, 2013, at 12:09 AM, Qianqian Ma maqian12@uga.edu<mailto:maqian12@uga.edu> wrote:
Dear Dr. Borrett,
I read Dr. Ulanowicz's paper "Quantitative methods for ecological network analysis". The computation of Ascendency, Overhead and Development capacity uses the flow matrix (T), which represents the flow among compartments within the system. The boundary input and output is not used.
Your R package (enaR) computes these three measures. The flow matrix you used include not only the flows among compartments, but also the boundary input (z) and output(y). This is equivalent to include the environment as one extra compartment. Both computations make sense to me, but I wonder why you want to include the environment for these three indices. Is there any particular reason you modify the original definition? Thanks.
Qianqian Ma Phd student College of Engineering University of Georgia Athens, GA 30602 Web: https://sites.google.com/site/maqian12/
Matt and Dave,
I finally found a computer that could run Dr. Ulanowicz's NETWRK function. I applied it to the version of the cone springs model that we have in our library and compared our Information Indices output to NETWRKS. I also verified that the model we have in our library matches the one being used in several sources.
Given the same input model, I am getting the same (1) TSTp, (2) development capacity, (3) ascendency, (4) and A/C ratio. The NETWRK program does not return the AMI or a single combine overhead number, and our function does not returns several indices that are included in the NETWRK function. These include:
Overhead on Imports Overhead on Exports Dissipative Overhead Redundancy Internal Capacity Internal Ascendency
What is really intriguing to me is that the values NETWRK is reporting are different than the values reported the literature. Specifically, the values in Kay, Graham, and Ulanowicz (1989) do not match. However the Ascendency number for the Cone Springs model reported in Ulanowicz (1986) is the same as in Kay et al. (1989)!
No wonder we are all confused!
I also verified that the values were the same for the Crystal River (control) model.
Given the partial match between NETWRK and enaR, I am feeling better about our calculations.
Dave -- when you have a chance could you please add the indices mentioned above that are returned by the NETWRK package to the enaAscendency function? It would be good for us to be able to match the NETWRK output as best we can. This can wait until you have revised your manuscript.
Thanks all.
Stuart