|
|
|
Re: Features in Version 2 - some ideas [message #561754 is a reply to message #561731] |
Wed, 02 December 2009 23:49 |
Stefan Edlund Messages: 127 Registered: July 2009 Location: IBM |
Senior Member |
|
|
Hi Matthias,
these are all very good suggestion, let me try and comment on some of them but I'm sure others have some thoughts on it as well.
As for the feature request, that's what we originally wanted to do but there really isn't any other suitable forum provided by eclipse where anybody can easily provide input, unless we write the web app ourselves :) A wiki page was suggested but that might be too difficult to use for general audience.
I'm not sure I understand your first suggestion. If you know the distribution of farm size and the number of farms in each district, wouldn't you be able to roughly estimate the number of cattle in each district? That could then easily be incorporated into a STEM model.
We do not have a "parameter sensitivity" estimate right now, but I can see it being incorporated into the Experiment features in STEM. Experiments allow you to run many simulations varying all the values of the disease model parameters (either automatically or manually). I think it is a good suggestion. If you could give us an indication of the "importance" of such a feature to a public health person such as yourself it would be very helpful to us. It is actually possible to manually calculate the sensitivity of each parameter right now by looking at the log files generated when running experiments, but that would require some skills.
I don't know what the traffic light principle is. STEM allows you to compare the outcome of one simulation with another, and even compare simulation results with actual reference data if available. Perhaps you can explain this feature a little more?
The ability to add/remove nodes and edges from within the application has been requested many times so we need to do it for sure. One complication is that models in STEM points to graphs in the standard STEM library that cannot be modified. So one alternative is to make a copy of all the nodes/edges in the STEM library when you incorporate them into your model so you can edit them. However, the STEM libraries can be HUGE (like every region on the planet) so that might not be the best solution. A better solution is to keep a "change" log where the modifications done by the user are applied on top of the STEM library ones.
Importing other file formats into STEM is easier for some formats than other right now. We support ESRI shape files for GIS data for instance, but other formats would require more work. Is there any particular format that you encounter frequently that would be useful?
Regards,
/ Stefan
|
|
|
|
Re: Features in Version 2 - some ideas [message #561811 is a reply to message #561754] |
Tue, 08 December 2009 16:46 |
Matthias Filter Messages: 75 Registered: July 2009 |
Member |
|
|
Hi Stefan,
To Stefan's comments:
to the first point - nodes without GIS information:
Maybe the example was not the best. Of course you could work something around the issue, if you don't have the exact position of a node, but this is extra work for the user that simply wants to apply STEM to e.g. a simple edgelist. In the end this might prevent potential users from applying STEM. So e.g. in the area I'm working in, there we have the situation, that we don't want to locate the farm or the production site on a map, because this would cause problems with data privacy. So actually for me the question is whether it is much effort to open the system for that kind of data, because the simulation infrastructure, e.g. the epidemiological models and the simulation infrastructure connected with them, are as far as I understood not directly affected by the exact location of the node.
So if this (nodes without GIS) would be possible then one could also extend the STEM functionality with features from the graph theory community that can help to descibe the network used in a simulation, e.g. distribution of the indegrees or outdegrees of nodes etc.. One solution might be that one assigns manually the same coordinates to all nodes where exact locations are missing and the system then applies some jittering when it comes to displaying the network. But this is for sure just one possibility.
- parameter sensitivity issue:
your idea is very good, the Experiment features should be able to cover this. For me personally a sensitivity analysis would be a must if I would have to base a decision on a simulation (except I can verify my simulation with independent historical real world date). But to be honest I don't have to make that kind of decision here.
- traffic light principle means a simple three colour coding scheme, red is bad and green is good.
to the other things I comment later.
Matthias
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.04501 seconds