WIP - add some boolean indicators for OCP

[PierreMartinon]

[NB. The PR is not ready yet!]

Hi @ocots, @jbcaillau
I started to add a few boolean indicators for the OCP, that I originally introduced in the DOCP struct. You can find them in Model.jl

I started with

    has_free_initial_time::Bool
    has_free_final_time::Bool
    has_lagrange_cost::Bool
    has_mayer_cost::Bool

I also have a bunch of indicators and dimensions for the different kinds of constraints, that I think belong to CTBase as well. Any comments before I add them ?

    # OCP constraints
    # indicators
    has_control_constraints::Bool
    has_state_constraints::Bool
    has_mixed_constraints::Bool
    has_boundary_conditions::Bool
    has_variable_constraints::Bool
    has_control_box::Bool
    has_state_box::Bool
    has_variable_box::Bool

    # dimensions
    dim_control_constraints::Int64
    dim_state_constraints::Int64
    dim_mixed_constraints::Int64
    dim_path_constraints::Int64
    dim_boundary_conditions::Int64
    dim_variable_constraints::Int64
    dim_control_box::Int64
    dim_state_box::Int64
    dim_variable_box::Int64

[ocots]

I am OK but don't forget to not use the fields but use calls to function.

[PierreMartinon]

I am OK but don't forget to not use the fields but use calls to function.

Sure, there are actually no fields for the booleans, only the functions :D
For the dimensions I may have to add the fields and set them for instance in nlp_constraints, but I'll add getters for them.

[jbcaillau]

@PierreMartinon second thoughts: if they are more or less already present in CTBase.jl (some are, actually), why wouldn't we export them fromCTBase.jl and reuse them in CTDirect.jl? For those being setters / getters on an OCP, the logical place is indeed CTBase.jl, while for those related to a DOCP, the right place is CTDirect.jl.

[PierreMartinon]

@PierreMartinon second thoughts: if they are more or less already present in CTBase.jl (some are, actually), why wouldn't we export them fromCTBase.jl and reuse them in CTDirect.jl? For those being setters / getters on an OCP, the logical place is indeed CTBase.jl, while for those related to a DOCP, the right place is CTDirect.jl.

Exactly ! It just happens that most did not seem to exist in CTBase already, unless I missed them, which is possible. Tell me if you spot redundant ones in what I added

export has_free_final_time, has_free_initial_time,
 has_lagrange_cost, has_mayer_cost

export dim_boundary_conditions, dim_control_constraints, 
dim_state_constraints, dim_variable_constraints,
dim_mixed_constraints, dim_path_constraints, 
dim_control_box, dim_state_box, dim_variable_box

[PierreMartinon]

@ocots @jbcaillau On a side note, are you ok with the convention to set variable_dimension to 0 for variable-independent problems ? It would simplify things a bit for me.

[jbcaillau]

@ocots @jbcaillau On a side note, are you ok with the convention to set variable_dimension to 0 for variable-independent problems ? It would simplify things a bit for me.

Yes

[jbcaillau]

@PierreMartinon seems to be still WIP, so I have updated the title

[PierreMartinon]

And while I'm on CTBase, do we agree to rename OCPInit to OptimalControlInit ?

[PierreMartinon]

Ok, I think we can merge @ocots @jbcaillau :

• I did not touch variable_dimension and instead kept internal dims for x,u,v in the DOCP (since we already have a separate state dimension anyway for the possible lagrange cost reformulation)
• similarly, I kept the OCPInit renaming for a future PR

[ocots]

See comment about consistency.

[ocots]

I am wondering about consistency since it seems that the fields containing infos about dimensions and so the getters will return the right values only after the function constraint has been called once. We may add a function to set the dimensions and set them when:

• a getter is called if it was not set
• a constraint is added
• a constraint is removed
• ...

But I am not sure that this is the right thing to do.

[ocots]

@PierreMartinon I think you haven't reply to this comment. I think it is quite important.

[PierreMartinon]

@ocots Indeed I missed it. More precisely, the constraints dimensions are set in nlp_constraints since this is where the different kinds of constraints are parsed.

Ideally, the various dimensions would be updated at each constraint! call, but I don't think it's worth the effort. These are pretty internal parameters, and are supposed to be called only after the ocp is fully defined.

Maybe change the default value to -1 instead of 0 to make it more obvious ?

[PierreMartinon]

Edit: erf, -1 is not compatible with Dimension type. Just let it be ? If you prefer I will revert to dimensions internal to CTDirect

[ocots]

I would replace OCPInit by OptimalControlInit.

[PierreMartinon]

Ok, done :D