Hi Aditya
Thanks for your careful thoughts and good comments on this problem.
Regarding the suggested implementation, I would suggest that you look at
the ida_analyse.c file in solvers/integrators. Also look at
ascend/integrator for the API specific to integrators. We are trying to
use the Integrator API for all dynamic solvers, whereas the Solver API
is used for steady-state (NLA and NLP) problems. So I don't think that
slv_presolve is the right place for the code you are proposing.
I understand your comment about not having to include index reduction in
order for this algorithm to work. Perhaps as a first step, we could use
this algorithm to *alert* the user about the likely need for index
reduction in their problem, even if we don't actually implement it yet?
You mention that the algorithm is O(n²). Is "n" the number of variables
in this case, or the number of variable-relation edges? Does the
sparsity of the incidence matrix of problem come into play?
You had some doubts filed in your document:
* Regarding the point where flat vars/equations are
created/accessible, check out the "anaylsis" info at
http://ascend4.org/Integrator_API#Analysis and also
http://ascend4.org/Developer%27s_Manual#Analyser. Sorry for the
inconsistency of US/GB spelling here!
* I think that if you look at the ida_analyse stuff, and also possibly
the ascend/integrator stuff, you may be able to identify a
solver-independent place to put this proposed debugging code for
dynamic (integrator) systems. It will need some careful thought
though. Definitely our preference would be for this debugging to be
separate from the numerical code for the solver itself if possible.
Regarding your second suggestion about meaningful error messages etc,
that's definitely what we're aiming for. We're not there yet; I hope you
will help us. We have implemented various useful tools for steady-state
solvers, etc "Show fixable variables" and "Check" button; ideally we
could construct the GUI in such a way that these functions are
replaced/supplemented with suitable alternatives in the case that the
use is attempting to solve a dynamic problem. Note that sometimes a user
will want to switch between dynamic/steady solvers, however, so GUI
design is a bit tricky.
Finally, note that Ksenija wrote the recent 'ksenija2' branch, which
implements the functionality for switching behaviour in dynamic models.
That greatly complicated the debugging process. You should consider
that, and come up with a strategy for eventually supporting debugging of
models with boundary-switching. My suggestion would be to allow the user
to turn on the debugging function after *every* boundary event. It would
be slow, but safe.
Cheers
JP
On 11/03/15 06:52, aditya jain wrote:
> Hi,
>
> Thank you for the detailed response. I have done the required reading
> and have documented my understanding of the various aspects of the
> project in the following document :
> https://docs.google.com/document/d/1rGqABpdIOaIcIUCID9nsz3neMwPmbMoyhvaGwT0gjvM/edit?usp=sharing
>
> I have answered the two specific questions under the "Suggestions"
> heading of the document. I have also worked out two examples
> explicitly as suggested. I have a couple of doubts regarding the
> project which I have mentioned under the "Doubts" heading in the above
> document. I would be obliged if anyone could help clear those doubts
> or provide a direction towards a better understanding of those issues.
> Please feel free to comment if you have any suggestion with respect to
> any part of the document.
>
> Thanking you,
> Aditya Jain
> Undergrad – 3rd year
> IIIT- H , India
>
>
>
> On Sun, Mar 8, 2015 at 4:52 AM, John Pye <[email protected]
> <mailto:[email protected]>> wrote:
>
> Hi Aditya
>
> Welcome to ASCEND! I'm pleased that you're interested in becoming
> involved.
>
> For the project you are proposing I suggest that you should
> probably start with the code in the 'ksenija2' branch of our
> repository, which has our 'state of the art' ODE/DAE modelling
> code. Ksenija previously worked on event handling and boundary
> traversal in that solver, and we want to build on that code rather
> than start something new in parallel. There's a fair bit you to
> read and absorb, starting with the underlying IDA solver (check
> out the SUNDIALS documentation for that) then our Developers
> Manual on the wiki which will give you an overview of the ASCEND
> architecture.
>
> A couple of open questions for your consideration:
>
> * how feasible is it for us to add support for the Soares and
> Secchi algorithm, including support for index reduction (I
> believe it's a necessary part of their algorithm -- please
> check that for me) in ASCEND? what would be the best approach?
> * what can we do to make dynamic models in IDA easier to use and
> easier to debug?
>
> For the first one, I suggest you read the code and consider the
> options. In the second, I suggest you also make sure you've built
> up your own dynamic model from scratch, and gone through all the
> steps of debugging it yourself.
>
> Before we proceed with index reduction and the Soares/Secchi
> approach, we will need to discuss and agree on an approach. I
> suggest you open a discussion on our mailing list once you have
> done the necessary reading.
>
> Cheers
> JP
>
>
> On 08/03/15 08:26, aditya jain wrote:
>> Dear Dr John PYE,
>>
>> I am Aditya Jain, a 3rd year undergraduate student from
>> International Institute of Information Technology, Hyderabad
>> (IIIT-H), India. I am currently pursuing a 5 year dual degree
>> course comprising of B Tech in Computer Science and MS (by
>> research) in Computational Natural Sciences. I have been involved
>> with both programming and study of Chemistry since my freshman
>> year. I recently came across the project entitled "*Debugging
>> tools for DAE modelling*". on the Student projects
>> <http://ascend4.org/Student_projects#Reaction_kinetics_data_support> page
>> for ASCEND and wish to contribute to the same.
>>
>> This project appealed to me because it stands at the confluence
>> of my areas of interest which include Programming, Mathematics
>> (specifically Graph Theory) and Physical Chemistry. I have gone
>> through the research paper entitled "*Debugging for
>> Equation-Oriented CAPE Tools*" and discovered that the algorithms
>> are implementable with ease. Having taken courses like 'Topics in
>> Physical Chemistry', 'Optimization Methods' and 'Computational
>> Natural Sciences Lab', and served as a Teaching Assistant for
>> 'Mathematics I (Discrete Mathematics)' , I believe that I have
>> the required expertise for this project. I have used a number of
>> simulation tools during these courses and always had the desire
>> to contribute to the designing of one. I am comfortable with
>> programming in both Python and C since I have been doing it since
>> my freshman year and have done some projects in both of them.
>>
>> I realize that the demands of the project overlaps to a large
>> extent with what I am looking to work on in my summer project. I
>> shall be highly obliged, if given the opportunity, to contribute
>> to ASCEND.I request you to please guide me with some directions
>> in which I can proceed so as to get started with the same. I have
>> also attached a copy of my CV for your kind perusal and look
>> forward to hearing from you soon.
>>
>> Thanking you in advance,
>> Aditya Jain
>> Undergrad – 3rd year
>> IIIT- H , India
>>
>> ᐧ
>
>
------------------------------------------------------------------------------
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
