CsnowyLstar / HoGRC

Higher-order Granger reservoir computing
MIT License
12 stars 3 forks source link

about structural inference of subsystems #3

Open github-lyj opened 4 days ago

github-lyj commented 4 days ago

Dear author, I am deeply appreciative of the code you have shared, and have gained tremendous insights from your paper. However, I find myself puzzled about the methodology for inferring interactions between subsystems. My current understanding is that the files 'edges_ex.csv' and 'edges.csv' are instrumental in this process. What perplexes me is the rationale behind the numerical configurations in 'edges_ex', and how it synergistically works with 'edges'. I am eagerly looking forward to your clarification on this matter. Many thanks in advance for your time and assistance!

CsnowyLstar commented 3 days ago

Thank you for your attention to our work!

It should be noted that if you're not considering network dynamical systems (NDSs, as shown in Eq. 14 of the main text), you won't need to consider the structure of 'edges_ex.csv'. Otherwise, since the interaction structure in NDSs are the same (with different weights), we can record the common interaction conditions between subsystems using 'edges_ex.csv' (corresponding to the interaction dynamics G).

Here, we use a triplet ([u],[v],[w]) to record this coupling interaction structure, where the first element represents the node of the subsystem $i$ being driven, the second element represents the neighbor in the coupling subsystem $j$ that influences u, and the third element represents the neighbor within subsystem $i$ that influences u. Moreover, both v and w are located in the interaction dynamics G.

Of course, this is just a simple way of recording, which can clearly document the several systems considered in our work. For more complex situations, a more detailed method of recording may be required.

github-lyj commented 23 hours ago

Many thanks for your response. If my aim is simply to uncover the relationships among nodes within a single system, where every node has just one characteristic, would it be accurate to regard this system as a subsystem and configure the parameters as n=1 (signifying we're dealing with one feature) and V equal to the total number of nodes? Is it correct that I should not set n equal to the number of nodes and V to 1? Between these two setups, should the former generally be preferred?

CsnowyLstar commented 12 hours ago

Yes, in our code, 'n' represents the number of subsystems, and 'V' represents the number of nodes contained within a subsystem. When NDS is not considered, 'n' equals 1, and 'V' equals the total number of nodes (in this case, all structural information is reflected in the "edges_in.csv" file).