Multi-scale models

[rafaqz]

Multi-scale models with hierarchical grids should be possible here. Essentially this just requires relaxing the "All grids are the same size" rule, and allowing users to write interactions between different scale grids.

It does need some care, because we use @inbounds on reads and writes as the grid size is known, and we shouldn't lose that capability. Probably the ideas of a SimData level gridsize would need to change. We could also use a MultiscaleSimData object to handle these differences.

[rafaqz]

Maybe grids need a MultiScale wrapper (applied to init) that specifies the scaling factor as an Int would allow us to still use @inbounds.

[rafaqz]

An AggregateRule could deal with aggregating grid between scales, where state is a Window neighborhood you can e.g. sum.

[kivo360]

Maybe a PartitioningRule could help you group interactions between grids based on their movement properties and ingress/egress interactions. BTW, I came in to say hi. I'm an instant fan of your work.

[rafaqz]

Thanks! And thanks for fleshing out the random thoughts I left here. You're right, the rule should allow both ingress and egress accross scales.

Do you have a use-case for this? Feel free to add any other ideas you have. Or make issues for other things. I'm working on broadening the context to fields outside ecology/biogeography, but dont necessarily know what people will want to do beyond doing a shallow lit review.

[kivo360]

The biggest use-case would be to improve how the scales are grouped together. Layers of reality tend to stratify in different ways based on the properties of them. For instance, ink and water would blend well together. Yet, if you place water and oil together they would move in a different way. They wouldn't blend more than a course surface of one entering into another.

Having a rule in place for that would ultimately reduce the computational cost. Because if you have to do less computing for layers that don't blend often, and can group the sets that do blend often, you can reduce the overall distance data would have to travel.

Another thing to keep in mind. In some instances, ingress and egress rules will become apparent over time and can't be planned nor written in advance. For instance, you let's say somebody brings in a new species that is not native to the land. That species would cause an entire network of interactions among the existing species that wouldn't match any previously existing model.

[kivo360]

One more thing. I see tons of use-cases outside of ecology and biogeography. One thing to note is that by not focusing you might miss out on the golden nuggets inside of the fields you already have. I personally would want to use this software for computational chemistry and things around that field. However, I'd reason your current use cases are a serious handful already.

[rafaqz]

Thanks for the comments. Computational chemistry is an application I hadn't considered, that's interesting.

Really most of the work here was in the general grid mapping engine here and in tooling (e.g. ModelParameters.jl/DimensionalData.j/Flatten.jl/DynamicGridsInteract.jl etc), more than ecology specific things. So it's good if it has broader use cases to justify it and sustain things in future. We also do applied ecology and models can incorporate rules from genetics to agricultural economics... so improving the generality mostly helps us too.

[kivo360]

Can I email you then? I'd like to throw some ideas. There's a lot of write and I'd also like to keep them (relatively) non-public for a few of weeks (3-4). I also want to see if you could take them and create something beautiful with them. I imagine you pursuing them would set off a series of events and I'd like to be able to keep up when you do so. I'm just not entirely ready for that yet.

On Tue, May 4, 2021, 8:22 PM Rafael Schouten @.***> wrote:

Thanks for the comments. Computational chemistry is an application I hadn't considered, that's interesting.

Really most of the work here was in the general grid mapping engine here and in tooling (e.g. ModelParameters.jl/DimensionalData.j/Flatten.jl/DynamicGridsInteract.jl etc), more than ecology specific things. So it's good if it has broader use cases to justify it and sustain things in future. We also do applied ecology and models can incorporate rules from genetics to agricultural economics... so improving the generality mostly helps us too.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/cesaraustralia/DynamicGrids.jl/issues/116#issuecomment-832387649, or unsubscribe https://github.com/notifications/unsubscribe-auth/AASKXKFL3KNKM4JN6C3BGIDTMC2WBANCNFSM4XZJEGCQ .

[rafaqz]

Sure, that sounds great. Its rafaelschouten at gmail