Thanks for your suggestions. I am pasting a copy of my previous comments
below, for the benefit of the mailing list.
Regarding your comment (2), I think this could work very well, providing
that we implement an "undo" feature, so that if the model diverges
because of a wrong value entered, we can still get the good model state
back again. I think that it would be very helpful to read the Gamma et
al ('gang of four') book on Design Patterns for this work. For example,
that book has suggestions on ways to implement 'undo' mechanisms, and
other related stuff. Note that we already have many of the things you
refer to in your email. The project really requires that you get the
current code up and running now so that you can give a detailed analysis
of where the work needs to be done. Preferably, you would give us some
evidence that you are able to do the work, by essentially starting the
work or else fixing some related minor bugs, etc.
Regarding comment (3), I think it would be quite helpful to figure a new
file format for loading/saving canvas files. We would like to include
the solved values for the canvas, as well as the configuration of the
canvas. It would make the canvas files far more useful, because they
would serve as a record of a solution, as well as a record of the system
being modelled. One could save the file, and load it elsewhere,
continuing the work of not just creating the model but solving it,
examining 'scenarios', etc.
Please continue to develop your proposal -- I look forward to seeing the
results, and hopefully we can progress with the project.
Cheers
JP
On 22/03/15 04:15, Ankush Jindal wrote:
> Hi,
> I have worked around basic workflow for the canvas modeller.
> The basics requirement for modeller would be to -
> 1) Define the canvas-based model
> (http://ascend4.org/Canvas-based_modeller_for_ASCEND#Loading.2C_saving_and_solving_canvas-based_models)
> and then make methods to define variable, and at same time keeping
> track of free/fixed variables. The model should be marked complete
> when set of parameters are enough for defining the system.
> 2) Compute the module and report back values, with at same time
> allowing feedback, that is user can change parameters and get the
> changes in /real-time. /The result could then be displayed in block
> model itself, color coding the parameters selected and variable outcome.
> 3) Saving the result, simulation and the model could be a stretch goal.
>
> I have set up the development environment for ASCEND and also reading
> about Gaphor <https://github.com/amolenaar/gaphor>.
> Kindly comment on the workflow, so that we can move on to the project
> proposal.
>
>> -
>> Ankush Jindal
>> Student, IIT Mandi, India
>> Phone: +91-9805901195
>> Github: travis-bickle
>> Facebook: jindalankush95
>>
>
On 16 March 2015, John Pye wrote:
> Hi Ankush
>
> Thanks for your interest in our project. You asked for suggestions
> about our canvas-based modeller. This area of ASCEND is a tricky one:
> we want to make it intuitive and /visual /to develop flowsheet models
> in ASCEND. The main domain of application is in chemical process and
> energy system modelling. Comparable modelling tools are ASPEN, gPROMS,
> Simulink/Xcos, DWSIM (open source) and others. Rather than writing
> text-based models, we want a good GUI that exposes all the needed
> features. The GUI already implements the idea of defining what the
> 'blocks' in the model would be, but doesn't (yet) have a really good
> system for exposing what the 'unknowns' for each model are. At
> present, we annotate special model files using our NOTES syntax in
> such a way that the Canvas GUI can make an appropriate visual
> representation of the units, and also request the values of the
> required parameters for each block. We don't yet have a way to specify
> parameters for the *connections* in the model; that's probably
> important, because in chemical processs simulations it is common to
> specify the components (chemical species) present in each process
> stream. We don't yet have a nice way to do that, and we don't have a
> clear idea about what the correct architecture for that will be.
>
> Also in the Canvas GUI, we don't yet have a nice way to report values
> back to the user in a nice way, via numerical read-outs on the canvas
> itself. For example, it would be nice (as the user) to be able to
> request that certain pressures and temperatures be shown on the
> canvas. When parameters in the simulation are changed, the key
> pressures and temperatures all over the process could easily then be
> reviewed. Other values might also be added, eg calculated
> efficiencies, heating rates, etc. It would be nice to have a flexible
> process for adding numerical 'indicators' or 'read-outs' on the
> canvas. We don't have that yet; it would require a bit of thought as
> to how best to define that.
>
> Finally, we don't yet have really robust file save/load functionlity
> for the canvas GUI. It would be great to extend the GUI so that
> simulation results could be stored within the file. When the canvas
> (flowsheet) is changed, the stored results would need to be
> invalidated, but hopefully not thrown away. If a model has been solved
> and then changed (eg different parameters set, etc) then we need a way
> to re-use the previous solution, to speed up the solution of the
> modified flowsheet. Ultimately, we would like to have the ability to
> store multiple 'scenarios' in the stored model file. This kind of
> approach allows different design-cases to be tested within a single
> flowsheet file. But we have to start with the simpler case first!
>
> There you go... a few ideas. Hope that helps,
>
> Cheers
> JP
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Ascend-sim-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ascend-sim-users
