Hi John,
I have been working on the proposal for past few days. I have now uploaded
it, kindly have a look on it.
-
Ankush Jindal
Student, IIT Mandi, India
Phone: +91-9805901195
Github: travis-bickle
Facebook: jindalankush95
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
