simplify using Refluxing with MoL

Comments (5)

Erik Schnetter

removed comment

A patch to introduce nvars_not_evolved_with_MoL would be grand.

Listing variables in strings is very non-MoL; MoL expects thorns to register variables at run time instead.

2013-06-18T21:14:55+00:00

Roland Haas reporter

removed comment

A patch, hmwell, yes, maybe, actually this ticket was more or less intended as a reminder for me to get around and provide just such a patch (I had assumed that I could use the "enhancement" category for this kind of thing).

I agree that list variables in a string is unusual for MoL. See below for a possibly different approach.

I am not really familiar with what Refluxing currently does, reading param.ccl though it seems that the user has to give the full list of variables in refluxing_variables and then tell Refluxing which ones to register with MoL based in the location in the string, ie. "register only the first nvars_evolved" variables with MoL. I am not sure if this is a very robust interface since it requires several parameters to be consistent with each other.

A different method would be a version where Refluxing takes the full list of variables, then queries MoL whether each variable is registered with MoL as an evolved variable (via a call to QueryRHS or whatever the aliased function is actually called) and only registers those fluxes with MoL that have RHS registered already. This would do away with the two separate parameters nvars_evolved and nvars altogether, which I would like very much.

Please note that this ticket is in not way intended as a "can someone please write this for me" ticket, but really only as a reminder to myself to write something like this or to gather opinions if this is a good interface.

No patch yet that implements this either.

2013-06-18T22:40:42+00:00

Frank Löffler

removed comment

This sounds to be related to ~~#1435~~, is this right?

2013-12-11T08:30:59+00:00

Roland Haas reporter

changed status to resolved
removed comment

Yes, this ticket is now a duplicate of ~~#1435~~ which does have an attached patch.

2013-12-11T10:28:27+00:00

Roland Haas reporter

changed status to closed
edited description

2019-02-21T20:13:12+00:00

Erik Schnetter
- removed comment
A patch to introduce nvars_not_evolved_with_MoL would be grand.

Listing variables in strings is very non-MoL; MoL expects thorns to register variables at run time instead.
- 2013-06-18T21:14:55+00:00
Roland Haas reporter
- removed comment
A patch, hmwell, yes, maybe, actually this ticket was more or less intended as a reminder for me to get around and provide just such a patch (I had assumed that I could use the "enhancement" category for this kind of thing).

I agree that list variables in a string is unusual for MoL. See below for a possibly different approach.

I am not really familiar with what Refluxing currently does, reading param.ccl though it seems that the user has to give the full list of variables in refluxing_variables and then tell Refluxing which ones to register with MoL based in the location in the string, ie. "register only the first nvars_evolved" variables with MoL. I am not sure if this is a very robust interface since it requires several parameters to be consistent with each other.

A different method would be a version where Refluxing takes the full list of variables, then queries MoL whether each variable is registered with MoL as an evolved variable (via a call to QueryRHS or whatever the aliased function is actually called) and only registers those fluxes with MoL that have RHS registered already. This would do away with the two separate parameters nvars_evolved and nvars altogether, which I would like very much.

Please note that this ticket is in not way intended as a "can someone please write this for me" ticket, but really only as a reminder to myself to write something like this or to gather opinions if this is a good interface.

No patch yet that implements this either.
- 2013-06-18T22:40:42+00:00
Frank Löffler
- removed comment
This sounds to be related to ~~#1435~~, is this right?
- 2013-12-11T08:30:59+00:00
Roland Haas reporter
- changed status to resolved
- removed comment
Yes, this ticket is now a duplicate of ~~#1435~~ which does have an attached patch.
- 2013-12-11T10:28:27+00:00
Roland Haas reporter
- changed status to closed
- edited description
- 2019-02-21T20:13:12+00:00
Log in to comment