I currently am working on a large sea grass model of Tampa Bay. The Bay is divided into ten sections with about 50,000 to 150,000 grid cells for each section. Growth is based on growth in cells and the exchange of seagrass between cells. Determining neighbor cells using boulean statements requires an hour or so whent he model is being compiled. Every time you restart simile we have to do this. Neighbors are stored in the model configuration in such a way that they cannot be saved as files. If we could just introduce them as files we would save a lot of time and more people in the regulatory field would use this software. It would probably also assist in uncertainty and sensitivity analysis. Is ther any way you can help with this? I use 5.94.
Comments
#1
Cannot one-sided enumeration be used to speed up the determination of neighboring cells? Does http://www.simulistics.com/examples/catalogue/animal-movement-and-interaction-their-environment help?
In any case, could the results be saved using the snapshot tool,
http://www.simulistics.com/help/diagrams/snapshot.htm
http://www.simulistics.com/help/diagrams/index.htm (Inspect a model variable).
In a version of the model using file parameters the previously calculated values could be read in, http://www.simulistics.com/examples/catalogue/representing-links-between-number-countries-using-association-submodel.
#2
The ideal solution would be to create the neighbour relation by base instance lookup, but currently that only works with one-dimensional arrays so would need a bit of manipulation to derive each hexagon's coordinates from its index. I could do you an example.
Simile v6.1, which will be out before Xmas, will have built-in rectangular and hexagonal grid submodel types, including functions allowing direct access to values from neighbours without using an association submodel.
#3
A couple of years back you helped me create the hex grid using lat and log values from GIS. It works very well except it takes a long time to compile. And you have to compile every time you change the mode in its development. I actually sent you my model back then. You commented back that you couldn't save a snap shot and then add it back into the model as a file. If one could it would be decoupled from the compiling process I would guess, greatly reducung compiling time. Since I work for a regulatory agency they want our models to be run on a desk top with a reasonably short run time. Will the new hex grids in 6.1 be usable with GIS lat and long data. Will we have to buy this or will it be an upgrade? or do previous users get a discount?
#4
Is the version you sent me (May 2012) still current? I'll have another go at extracting the neighbour relationship data into a file that can be loaded.
Simile v6.1 will be a free upgrade for users of the current major version, v6.0. This version is available as an upgrade at half price for customers currently using v5. In any case you can upgrade for free to v5.97, which is able to load models created or edited in v6.0 (as well as in earlier versions of course).
#5
What I remember is that you modified my approach to the boulean to include all neighbors at once but I don't remeber what I sent you. Why don't you tell me what you need and I will put it together and send that to you. What I do know is that I sent just section 1 of 10 so I 9 more to do. If you could give me a process for establishing the file that might be best. Thanks for your help.
#6
OK, I think I've worked out how to save the membership of an
association between members of 1-D arrays in such a way that it
can be used to recreate the association quickly using base
instance lookup.
Consider the first model attached here, savesnap. This shows an
association between instances of a submodel, in which the roles are
'here' and 'there'. It isn't important how the association membership
is set, but doing it for a large base membership is going to take a
long time (n^2). What we want to do is create a data file which will
allow us to set the membership using base instance lookup, i.e., data
in the instance in the 'here' role is going to be used to pick which
instances it partners in the 'there' role. Since we will be looking up
the latter, we need to check the 'allow base instance lookup' flag in
the properties of the 'there' role arrow.
Now we need to save the data. The component 'there_serial' in the
association has the equation:
if here_idx==in_preceding(here_idx) then in_preceding(prev(0))+1 else 1
The idea is to create a count for the indices of the looked-up
instances. here_idx is the index of the instance doing the looking-up
-- since the looked-up index is always index(1) in the association,
this is index(2). The count starts at 1 each time we get to a new
looker-up, and increments by 1 for each extra looked-up
instance. prev(0) just means "the value of this very component".
So, run the model, wait for the association to be calculated, then
take a snap of there_serial and save it. We will have a file that
starts something like this:
When we play this file back into the membership, there_serial will be
an index, and index2 (the id of the instance on the looked-up side,
actually index(1) in the equation language) will be the data point.
So on to the second model, loadsnap. Beacuse each base instance has a
different number of associations, we need to load the data into a 'per
record' submodel, nbrs. For each line in the data file, the outer
index (index1) says which base model instance it goes into, and the
inner index (there_serial) which instance of the per-record model,
which will have a different instance count in each parent instance. To
load the file, hit the 'values from file' button to the right of
nb_id's field in the file parameter dialogue, browse to the saved snap
file, and drag 'index1' and 'there_serial' from the column headings to
the 'Use as indices' box. Drag 'index2' to the 'Use as data' entry,
and hit 'OK' to load.
Now it should be possible to use the values of nb_id directly in the
association condition to look up the 'there' members, but there is a
bug in simile (gasp) which has the effect that you cannot use values
from a fixed-membership submodel of a base model directly to look up
its associations, and a per-record submodel is fixed-membership once
the data is loaded. That will be fixed in v6.1, but in the mean time
we must work around it -- by copying the data to a variable-membership
submodel, nbrs_vm. This has a single dimension which is the maximum
number of associations each base model can have -- that would be 6 for
hex grid neighbours. But its condition, index(1)<=count([nb_id]), sets
the actual number to the same as the per-record submodel in each
instance. The equation for nb_id merely picks the value from the
corresponding instance of nbrs. One final point -- make sure this variable has data type 'int'.
Now the values can be used in the condition of the association
submodel, which is 'any(index(1) is {here_nb_id})'. This means the
association exists for any instance on the 'there' side with an index
matching one of the values of the list 'nb_id' on the 'here' side, and
indeed you can check that it has the same membership as it did in
'savesnap' -- but was very much quicker to create. Once this is set
up, the reference to the association data file can be saved in a
parameter metafile along with the rest of the parameterization.
Hope this helps -- now I'll get on and fix that bug...
#11
#12
Automatically closed -- issue fixed for 2 weeks with no activity.