Avoid global pointers in dae

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Avoid global pointers in dae

Francesco Faccio-2

Hi! 

I'm writing a class IDA for ode15{i,s} which inherites from class DAE and I would like to avoid using global pointers.

In my dld-function I first create an object of class DAEFunc and I pass it as an argument for the constructor of my class (as it's done in daspk.cc):

DAEFunc func (ida_user_function);
IDA dae (t0, y0, yp0, func);


where ida_user_function is defined as 

ColumnVector
ida_user_function (const ColumnVector& x, const ColumnVector& xdot,
                     double t, octave_idx_type& ires)

and it uses a global pointer to the octave_function supplied by the user to compute residuals.

I would like to overload the constructor of DAEfunc in order to pass the pointer when I construct my object (and avoid declaring it as global):

typedef ColumnVector (*DAERHSFuncIDA) (const ColumnVector& x,
                                         const ColumnVector& xdot,
                                         double t, octave_idx_type& ires,
                                         octave_function *& ida_fcn);

DAEFunc (DAERHSFuncIDA f)
    : fun_ida (f), jac (0), reset (true) { }

and same for the Jacobian.

Since I don't own copiright, I would like to know if it's ok to change the interface of that base class.

Thank you,

Francesco


Reply | Threaded
Open this post in threaded view
|

Re: Avoid global pointers in dae

Carnë Draug
On 13 August 2016 at 06:30, Francesco Faccio
<[hidden email]> wrote:
> [...]
> Since I don't own copiright, I would like to know if it's ok to change the
> interface of that base class.
>

The ability to change the code is one of the main points behind GPL.
So yes, you can change the source.

Just beware that if the interface is public you should try to keep
backwards compatibility.  I grepped all of the Octave Forge for DAEFunc
and all of its subclasses [1] but couldn't find it being used so you
should be fine.

Carnë

[1] http://octave.org/doxygen/4.1/d9/d83/classDAEFunc.html

Reply | Threaded
Open this post in threaded view
|

Re: Avoid global pointers in dae

Carlo de Falco-2

On 14 Aug 2016, at 01:17, Carnë Draug <[hidden email]> wrote:

> On 13 August 2016 at 06:30, Francesco Faccio
> <[hidden email]> wrote:
>> [...]
>> Since I don't own copiright, I would like to know if it's ok to change the
>> interface of that base class.
>>
>
> The ability to change the code is one of the main points behind GPL.
> So yes, you can change the source.
>
> Just beware that if the interface is public you should try to keep
> backwards compatibility.  I grepped all of the Octave Forge for DAEFunc
> and all of its subclasses [1] but couldn't find it being used so you
> should be fine.
>
> Carnë
>
> [1] http://octave.org/doxygen/4.1/d9/d83/classDAEFunc.html

Francesco,

As Carnë's answer shows, your question is ill posed and leads to misunderstandings:

of course you can change the source, the GPL license grants you this right,
the real question would be whether that change would be accepted by Octave
developers in the main repository or not.

c.



Reply | Threaded
Open this post in threaded view
|

Re: Avoid global pointers in dae

Carlo de Falco-2

On 14 Aug 2016, at 02:11, Carlo de Falco <[hidden email]> wrote:

>
> On 14 Aug 2016, at 01:17, Carnë Draug <[hidden email]> wrote:
>
>> On 13 August 2016 at 06:30, Francesco Faccio
>> <[hidden email]> wrote:
>>> [...]
>>> Since I don't own copiright, I would like to know if it's ok to change the
>>> interface of that base class.
>>>
>>
>> The ability to change the code is one of the main points behind GPL.
>> So yes, you can change the source.
>>
>> Just beware that if the interface is public you should try to keep
>> backwards compatibility.  I grepped all of the Octave Forge for DAEFunc
>> and all of its subclasses [1] but couldn't find it being used so you
>> should be fine.
>>
>> Carnë
>>
>> [1] http://octave.org/doxygen/4.1/d9/d83/classDAEFunc.html
>
> Francesco,
>
> As Carnë's answer shows, your question is ill posed and leads to misunderstandings:
>
> of course you can change the source, the GPL license grants you this right,
> the real question would be whether that change would be accepted by Octave
> developers in the main repository or not.

To make this more clear, who holds copyright is pointless and referring to that
in your question is distracting.

The question is a technical question about the class design and functionality, not
a legal question about licenses and copyright.

> c.


Reply | Threaded
Open this post in threaded view
|

Re: Avoid global pointers in dae

Francesco Faccio-2


Carlo de Falco<[hidden email]> wrote:
>On 14 Aug 2016, at 02:11, Carlo de Falco <[hidden email]> wrote:
>
>>
>> On 14 Aug 2016, at 01:17, Carnë Draug <[hidden email]> wrote:
>>
>>> On 13 August 2016 at 06:30, Francesco Faccio
>>> <[hidden email]> wrote: 
>>>> [...]
>>>> Since I don't own copiright, I would like to know if it's ok to change the
>>>> interface of that base class. 
>>>>
>>>
>>> The ability to change the code is one of the main points behind GPL.
>>> So yes, you can change the source.
>>>
>>> Just beware that if the interface is public you should try to keep
>>> backwards compatibility.  I grepped all of the Octave Forge for DAEFunc
>>> and all of its subclasses [1] but couldn't find it being used so you
>>> should be fine.
>>>
>>> Carnë
>>>
>>> [1] http://octave.org/doxygen/4.1/d9/d83/classDAEFunc.html
>>
>> Francesco,
>>
>> As Carnë's answer shows, your question is ill posed and leads to misunderstandings:
>>
>> of course you can change the source, the GPL license grants you this right,
>> the real question would be whether that change would be accepted by Octave
>> developers in the main repository or not.
>
>To make this more clear, who holds copyright is pointless and referring to that
>in your question is distracting.
>
>The question is a technical question about the class design and functionality, not
>a legal question about licenses and copyright.
>
>> c.

Carlo, Carnë,

sorry, my question was not well posed and thank you for making this clear to me. 
I'm not still sure we can avoid global pointers wrt the design of Octave. Let me explain why:

In my dld-function I have a pointer to the octave_function provided by the user and I use it inside a  DAERHSFunc to compute residual. I use a pointer to this DAERHSFunc when I construct an object of my class.

Inside my class I have methods which allows me to interface with Sundials' types and functions. In particular, I use a lambda to pass a residual function (with fixed signature) to a function of Sundials (with fixed signature). 

The problem here is that I cannot use classes and methods of libinterp inside liboctave to compute residual, I can only put a forward declaration in my class.

My first and actual solution is to call inside my lambda a pointer (stored in the base class) to the DAERHSFunc defined in my dld-fun, so I can call methods of class octave_function and I avoid code duplication, but I need to declare the poiner to octave_function global in my dld-function.

What I was trying to do, was to store the octave_function pointer as member of my class and to pass it as a parameter when I dereference the pointer  to the DAERHSFunc  in my lambda.  But since it has incomplete type I get segmentation fault. 

I think I could avoid global pointers changing completely the constructor of my class, but then inheriting from DAE would be meaningless.

Do you have any suggestions or do you know some workaround to this?

Thank you,

Francesco


Reply | Threaded
Open this post in threaded view
|

Re: Avoid global pointers in dae

Carlo de Falco-2

On 15 Aug 2016, at 09:09, Francesco Faccio <[hidden email]> wrote:

>
> Carlo de Falco<[hidden email]> wrote:
> >On 14 Aug 2016, at 02:11, Carlo de Falco <[hidden email]> wrote:
> >
> >>
> >> On 14 Aug 2016, at 01:17, Carnë Draug <[hidden email]> wrote:
> >>
> >>> On 13 August 2016 at 06:30, Francesco Faccio
> >>> <[hidden email]> wrote:
> >>>> [...]
> >>>> Since I don't own copiright, I would like to know if it's ok to change the
> >>>> interface of that base class.
> >>>>
> >>>
> >>> The ability to change the code is one of the main points behind GPL.
> >>> So yes, you can change the source.
> >>>
> >>> Just beware that if the interface is public you should try to keep
> >>> backwards compatibility.  I grepped all of the Octave Forge for DAEFunc
> >>> and all of its subclasses [1] but couldn't find it being used so you
> >>> should be fine.
> >>>
> >>> Carnë
> >>>
> >>> [1] http://octave.org/doxygen/4.1/d9/d83/classDAEFunc.html
> >>
> >> Francesco,
> >>
> >> As Carnë's answer shows, your question is ill posed and leads to misunderstandings:
> >>
> >> of course you can change the source, the GPL license grants you this right,
> >> the real question would be whether that change would be accepted by Octave
> >> developers in the main repository or not.
> >
> >To make this more clear, who holds copyright is pointless and referring to that
> >in your question is distracting.
> >
> >The question is a technical question about the class design and functionality, not
> >a legal question about licenses and copyright.
> >
> >> c.
>
> Carlo, Carnë,
>
> sorry, my question was not well posed and thank you for making this clear to me.
> I'm not still sure we can avoid global pointers wrt the design of Octave. Let me explain why:
>
> In my dld-function I have a pointer to the octave_function provided by the user and I use it inside a  DAERHSFunc to compute residual. I use a pointer to thisDAERHSFunc when I construct an object of my class.
>
> Inside my class I have methods which allows me to interface with Sundials' types and functions. In particular, I use a lambda to pass a residual function (with fixed signature) to a function of Sundials (with fixed signature).
>
> The problem here is that I cannot use classes and methods of libinterp inside liboctave to compute residual, I can only put a forward declaration in my class.
>
> My first and actual solution is to call inside my lambda a pointer (stored in the base class) to the DAERHSFunc defined in my dld-fun, so I can call methods of class octave_function and I avoid code duplication, but I need to declare the poiner to octave_function global in my dld-function.
>
> What I was trying to do, was to store the octave_function pointer as member of my class and to pass it as a parameter when I dereference the pointer  to the DAERHSFunc  in my lambda.  But since it has incomplete type I get segmentation fault.
>
> I think I could avoid global pointers changing completely the constructor of my class, but then inheriting from DAE would be meaningless.
>
> Do you have any suggestions or do you know some workaround to this?
>
> Thank you,
>
> Francesco


Hi Francesco,

As a general

Can you provide links to lines in your code on bitbucket so we can follow more clearly what you are talking about?

Some more specific questions:

Are lambdas among the C++11 features that are acceptable to use in Octave 4.1?
Why is your class IDA inheriting from DAE? What methods from the base class are you actually using?

The most straightforward method I see for encapsulating a C callback function inside a C++ class
is the following:

1 - include a "static" member function in your class with the signature required by the C callback

 static int
 IDA::res_interface (realtype tt, N_Vector yy, N_Vector yp, N_Vector rr, void *user_data);

2 - use the void pointer user_data to pass the 'this' pointer of the current object
   
 static int
 IDA::res_interface (realtype tt, N_Vector yy, N_Vector yp, N_Vector rr, void *user_data)
 {
   IDA *self = static_cast<IDA*>(user_data);
   ...
 }

3 - you can now access the non static class member methods via the pointer

 static int
 IDA::res_interface (realtype tt, N_Vector yy, N_Vector yp, N_Vector rr, void *user_data)
 {
   ...
   self -> res_implementation (realtype tt, N_Vector yy, N_Vector yp, N_Vector rr)
 }

The reason for using this pattern is that you cannot form a C function pointer to
a non static class member method, while you can pass a pointer to the static member
method IDA::res_interface.

How does your design differ from this approach?
c.
 



Reply | Threaded
Open this post in threaded view
|

Re: Avoid global pointers in dae

Francesco Faccio-2


Carlo de Falco<[hidden email]> wrote:
> On 15 Aug 2016, at 09:09, Francesco Faccio <[hidden email]> wrote:
>
> >
> > Carlo de Falco<[hidden email]> wrote:
> > >On 14 Aug 2016, at 02:11, Carlo de Falco <[hidden email]> wrote:
> > >
> > >>
> > >> On 14 Aug 2016, at 01:17, Carnë Draug <[hidden email]> wrote:
> > >>
> > >>> On 13 August 2016 at 06:30, Francesco Faccio
> > >>> <[hidden email]> wrote:
> > >>>> [...]
> > >>>> Since I don't own copiright, I would like to know if it's ok to change the
> > >>>> interface of that base class.
> > >>>>
> > >>>
> > >>> The ability to change the code is one of the main points behind GPL.
> > >>> So yes, you can change the source.
> > >>>
> > >>> Just beware that if the interface is public you should try to keep
> > >>> backwards compatibility.  I grepped all of the Octave Forge for DAEFunc
> >>> and all of its subclasses [1] but couldn't find it being used so you
> >>> should be fine.
> >>>
> >>> Carnë
> >>>
> >>> [1] http://octave.org/doxygen/4.1/d9/d83/classDAEFunc.html
> >>
> >> Francesco,
> >>
> >> As Carnë's answer shows, your question is ill posed and leads to misunderstandings:
> >>
> >> of course you can change the source, the GPL license grants you this right,
> >> the real question would be whether that change would be accepted by Octave
> >> developers in the main repository or not.
> >
> >To make this more clear, who holds copyright is pointless and referring to that
> >in your question is distracting.
> >
> >The question is a technical question about the class design and functionality, not
> >a legal question about licenses and copyright.
> >
> >> c.
>
> Carlo, Carnë,
>
> sorry, my question was not well posed and thank you for making this clear to me.
> I'm not still sure we can avoid global pointers wrt the design of Octave. Let me explain why:
>
> In my dld-function I have a pointer to the octave_function provided by the user and I use it inside a  DAERHSFunc to compute residual. I use a pointer to thisDAERHSFunc when I construct an object of my class.
>
> Inside my class I have methods which allows me to interface with Sundials' types and functions. In particular, I use a lambda to pass a residual function (with fixed signature) to a function of Sundials (with fixed signature).
>
> The problem here is that I cannot use classes and methods of libinterp inside liboctave to compute residual, I can only put a forward declaration in my class.
>
> My first and actual solution is to call inside my lambda a pointer (stored in the base class) to the DAERHSFunc defined in my dld-fun, so I can call methods of class octave_function and I avoid code duplication, but I need to declare the poiner to octave_function global in my dld-function.
>
> What I was trying to do, was to store the octave_function pointer as member of my class and to pass it as a parameter when I dereference the pointer  to the DAERHSFunc  in my lambda.  But since it has incomplete type I get segmentation fault.
>
> I think I could avoid global pointers changing completely the constructor of my class, but then inheriting from DAE would be meaningless.
>
> Do you have any suggestions or do you know some workaround to this?
>
> Thank you,
>
> Francesco


Hi Francesco,

As a general

Can you provide links to lines in your code on bitbucket so we can follow more clearly what you are talking about?

Dear Carlo,

here's the link to my dld-function [1], to the header of my class [2] and its implementation [3].
In [1] line 71 there is the definition of the DAERHSFunc I call in line 230 where I construct my object.

>Are lambdas among the C++11 features that are acceptable to use in Octave 4.1?

I can compile Octave using lambdas, but as you asket I suppose that's not enough. Where can I check this?


Why is your class IDA inheriting from DAE? What methods from the base class are you actually using?

Since a dae solved by ode15i "is a" DAE and the design is pretty similar to daspk.cc, I think that it's the right place to be inside Octave. In IDA I call the constructor of the base class DAEFunc passing as argument a pointer to the DAERHSFunc and the constructors of base class base_diff_alg_eqn and base_diff_eqn. I call methods base_diff_eqn::time(), base_diff_eqn::state(), base_diff_alg_eqn::state_derivative() inside another method to initialize Ida solver and I dereference the function of the base class DAEFunc in order to compute residual ([3] line 70). 


> 2 - use the void pointer user_data to pass the 'this' pointer of the current object
>     
> static int
> IDA::res_interface (realtype tt, N_Vector yy, N_Vector yp, N_Vector rr, void *user_data)
>  {
>    IDA *self = static_cast<IDA*>(user_data);
>    ...
>  }

This is similar to what I do: my lambda can't capture any parameter because the signature would change. If the lambda doesn't capture anything, I still create a closure, but  I can pass the lambda as a pointer to function to IDAInit ([3], line 79). 

I store in user_data the pointer to the DAERHSFunc I want to call:

void IDA::set_userdata(void *& ida_mem)
{
  void * userdata = &fun;
  int flag = IDASetUserData(ida_mem, userdata);
}

and then, inside a method:

auto resfun = [] (realtype t, N_Vector yy, N_Vector yp, N_Vector rr, void *user_data)
{
...
DAEFunc::DAERHSFunc *data = static_cast<DAEFunc::DAERHSFunc *>(user_data);
DAEFunc::DAERHSFunc pointres = *data;
ColumnVector res = (*pointres) (y0, yp0, t, ires);  
...
};

int flag = IDAInit (ida_mem, resfun, t0, yy, yp);


>3 - you can now access the non static class member methods via the pointer

This is nice, but I can't write methods that compute residual inside my class. I need to call method do_multi_index_op or feval, which are defined in libinterp. That's why I dereference pointres to call function defined in [1] line 72. 
 
What I wanted to do to avoid global pointers was to overload the constructor of DAEFunc in order to call 

ColumnVector res = (*pointres) (y0, yp0, t, ires, ida_fcn);  

where ida_fcn is a octave_function *, but octave_function is an incomplete type inside liboctave.
The same problem affects the Jacobian evaluation.

We have 4 options I think:
- find a brilliant way to evaluate residual in liboctave avoiding global pointers (passing ida_fcn in some way)
-inherit from DAE and evaluate residual completely inside the dld-function (I can write resfun as a normal function and pass it to IDAInit)
-don't inherit from DAE and evaluate residual completely inside the dld-function
-use the global pointer as daspk, dassl, dasrt and other corefcn

In these days I became quite familiar with std::function, std::function::target, std::bind, so if there is a nice way to use them we can try something magic. 

Thank you for the hints,

Francesco

 
[1] https://bitbucket.org/Francesco_Faccio/octave/src/6f04dbbe5fdf147fbd95fb3ea8901e5fd61081a7/libinterp/dldfcn/__ode15__.cc?at=default&fileviewer=file-view-default
[2]https://bitbucket.org/Francesco_Faccio/octave/src/6f04dbbe5fdf147fbd95fb3ea8901e5fd61081a7/liboctave/numeric/IDA.h?at=default&fileviewer=file-view-default
[3]https://bitbucket.org/Francesco_Faccio/octave/src/6f04dbbe5fdf147fbd95fb3ea8901e5fd61081a7/liboctave/numeric/IDA.cc?at=default&fileviewer=file-view-default
Reply | Threaded
Open this post in threaded view
|

Re: Avoid global pointers in dae

Carnë Draug
On 15 August 2016 at 11:42, Francesco Faccio
<[hidden email]> wrote:
>
> Carlo de Falco<[hidden email]> wrote:
>
>>Are lambdas among the C++11 features that are acceptable to use in Octave
>> 4.1?
>
> I can compile Octave using lambdas, but as you asket I suppose that's not
> enough. Where can I check this?
>

Just check if they are already being used.  If so, it's safe.  Lambdas
are already used in Octave [1]

[1] http://hg.savannah.gnu.org/hgweb/octave/file/18535a29a8e8/libinterp/dldfcn/xzip.cc#l422

Reply | Threaded
Open this post in threaded view
|

Re: Avoid global pointers in dae

Carlo de Falco-2
In reply to this post by Francesco Faccio-2

On 15 Aug 2016, at 12:42, Francesco Faccio <[hidden email]> wrote:

> This is nice, but I can't write methods that compute residual inside my class. I need to call method do_multi_index_op or feval, which are defined in libinterp. That's why I dereference pointres to call function defined in [1] line 72.

I don't understand why not.

Can't you create a method that calls feval internally,
and pass a pointer to it with the standard technique shown
in the previous email?

Why?

c.


Reply | Threaded
Open this post in threaded view
|

Re: Avoid global pointers in dae

Carlo de Falco-2
In reply to this post by Francesco Faccio-2

On 15 Aug 2016, at 12:42, Francesco Faccio <[hidden email]> wrote:

> What I wanted to do to avoid global pointers was to overload the constructor of DAEFunc in order to call
>
> ColumnVector res = (*pointres) (y0, yp0, t, ires, ida_fcn);  
>
> where ida_fcn is a octave_function *, but octave_function is an incomplete type inside liboctave.
> The same problem affects the Jacobian evaluation.

Is there any special reason why you insist setting user_data to a function pointer to user function
instead of using the 'this' pointer of your IDA object?

That would look much more simple and natural to me because then you can implement anything you need
as a method in your class and you can also directly access all data stored in instances of that class ...

c.



Reply | Threaded
Open this post in threaded view
|

Re: Avoid global pointers in dae

Carlo de Falco-2
In reply to this post by Francesco Faccio-2

On 15 Aug 2016, at 12:42, Francesco Faccio <[hidden email]> wrote:

> Since a dae solved by ode15i "is a" DAE and the design is pretty similar to daspk.cc, I think that it's the right place to be inside Octave. In IDA I call the constructor of the base class DAEFunc passing as argument a pointer to the DAERHSFunc and the constructors of base class base_diff_alg_eqn and base_diff_eqn. I call methodsbase_diff_eqn::time(), base_diff_eqn::state(), base_diff_alg_eqn::state_derivative() inside another method to initialize Ida solver and I dereference the function of the base class DAEFunc in order to compute residual ([3] line 70).

None of these seems like indispensible to me ...

If you write your class as more independent
then your changesets will be less invasive
and more easily accepted, do you think that
would be possible?

c.



Reply | Threaded
Open this post in threaded view
|

Re: Avoid global pointers in dae

Francesco Faccio-2
In reply to this post by Carlo de Falco-2

Carlo De Falco wrote:

> On 15 Aug 2016, at 12:42, Francesco Faccio <[hidden email]> wrote:
>
> > This is nice, but I can't write methods that compute residual inside my class. I need to call method do_multi_index_op or feval, which are defined in libinterp. That's why I dereference pointres to call function defined in [1] line 72.
>
> Can't you create a method that calls feval internally,
> and pass a pointer to it with the standard technique shown
> in the previous email?

Finally I did it and it works without global pointers! 

The complication was this:
since libinterp (where classes octave_value, octave_function etc. are defined) depends on liboctave (where classes for corefcn and dld-fcn are defined), there is no way to include the headers required (ov.h, ov-fcn.h and others from libinterp/octave-value) for calling their methods.

You can see here the dependences of libinterp and here those of liboctave.

What I can do inside my class after a forward declaration is:
- declare a member of the class which is a pointer or reference to the incomplete type
-define functions which accepts/returns pointers or references to the incomplete type, but without using their methods

In my class I cannot store a member octave_function , because the compiler doesn't know anything about that type and I got:

error: aggregate ‘octave_function e’ has incomplete type and cannot be defined


And I cannot call directly a method of an incomplete time in any method, static or not, of my class.
Fortunately, I can store a pointer to the incomplete type and pass it as a parameter to the function:

ColumnVector res = (*funct) (y0, yp0, t, ires, ida_fun);

where ida_fun is the pointer to the incomplete type.
I dont' know if it was clear what was the complication here. I used the technique you suggested and it made the code a lot more simple than using lambdas.

Francesco

Reply | Threaded
Open this post in threaded view
|

Re: Avoid global pointers in dae

Francesco Faccio-2
In reply to this post by Carlo de Falco-2

Carlo de Falco wrote:

> On 15 Aug 2016, at 12:42, Francesco Faccio <[hidden email]> wrote:

> > What I wanted to do to avoid global pointers was to overload the constructor of DAEFunc in order to call
> >
> > ColumnVector res = (*pointres) (y0, yp0, t, ires, ida_fcn); 
> >
> > where ida_fcn is a octave_function *, but octave_function is an incomplete type inside liboctave.
> > The same problem affects the Jacobian evaluation.
>
> Is there any special reason why you insist setting user_data to a function pointer to user function
> instead of using the 'this' pointer of your IDA object?
>
> That would look much more simple and natural to me because then you can implement anything you need
> as a method in your class and you can also directly access all data stored in instances of that class ...
>
> c.
Carlo,

in that mail I was providing some code in order to explain better the differences between the design I implemented and the one you suggested, as you asked. Of course the example you showed is easier to implement and make the code less rigid. I have already removed lambdas and the pointers passed through user_data.

Thank you,

Francesco

Reply | Threaded
Open this post in threaded view
|

Re: Avoid global pointers in dae

Francesco Faccio-2
In reply to this post by Carlo de Falco-2

Carlo De Falco wrote:

> If you write your class as more independent 
> then your changesets will be less invasive
> and more easily accepted, do you think that
> would be possible?

> c.

Sure! I am going to update my repo as soon as I refactor my code.

Thank you again,

Francesco


Reply | Threaded
Open this post in threaded view
|

Re: Avoid global pointers in dae

Francesco Faccio-2


Carlo De Falco wrote:
> If you write your class as more independent 
> then your changesets will be less invasive
> and more easily accepted, do you think that
> would be possible?

> c.

Hi Carlo!

I wrote the class without inheriting from DAE and avoiding global pointers for residual function and jacobian evaluation. 

You can see the new design of the dld-function [1] and the class [2][3]. Your suggestion really helped.

I'm going to complete the options of the solver. I've already written some test here [4]. In the m-interface I use a private function to check odefun, tspan and init [5]. I think we could adapt it also for ode23 and ode45.

Francesco

[1]https://bitbucket.org/Francesco_Faccio/octave/src/357028bea81fc0c6b0910afd7ea4154bb98034b2/libinterp/dldfcn/__ode15__.cc?at=default&fileviewer=file-view-default
[2]https://bitbucket.org/Francesco_Faccio/octave/src/357028bea81fc0c6b0910afd7ea4154bb98034b2/liboctave/numeric/IDA.h?at=default&fileviewer=file-view-default
[3]https://bitbucket.org/Francesco_Faccio/octave/src/357028bea81fc0c6b0910afd7ea4154bb98034b2/liboctave/numeric/IDA.cc?at=default&fileviewer=file-view-default
[4]https://bitbucket.org/Francesco_Faccio/octave/src/357028bea81fc0c6b0910afd7ea4154bb98034b2/scripts/ode/ode15i.m?at=default&fileviewer=file-view-default
[5]https://bitbucket.org/Francesco_Faccio/octave/src/357028bea81fc0c6b0910afd7ea4154bb98034b2/scripts/ode/private/check_default_input.m?at=default&fileviewer=file-view-default

Reply | Threaded
Open this post in threaded view
|

Re: Avoid global pointers in dae

Francesco Faccio-2

Francesco Faccio wrote:

> Carlo De Falco wrote:
> > If you write your class as more independent 
> > then your changesets will be less invasive
> > and more easily accepted, do you think that
> > would be possible?
> >
> > c.
>
> You can see the new design of the dld-function [1] and the class [2][3].

Carlo, 

I discussed with Carnë the right place where to put class IDA. Since liboctave is independent from libinterp and my code needs to work with libinterp methods, it's better to put it in libinterp directly. 

I updated my repo, so you can find dld-fun and class here:

https://bitbucket.org/Francesco_Faccio/octave/src/80455602cffaf663c7513c6447b03887b32bf02e/libinterp/dldfcn/__ode15__.cc?at=%40&fileviewer=file-view-default

Francesco