Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suggested feature: solve() should not return dictionary, rather it should return an object called Solution #76

Open
cmower opened this issue Feb 16, 2023 · 2 comments
Labels
enhancement New feature or request future Plans for the future. help wanted Happy to accept pull requests

Comments

@cmower
Copy link
Owner

cmower commented Feb 16, 2023

Currently, the solve() method returns a dictionary containing the solution. I'm proposing here that we should implement a solution class that has the solution data packed inside but also comes with some useful methods.

For example, it could look something like the following.

import casadi as cs
from dataclasses import dataclass
from typing import Dict, List
from .models import Model

@dataclass
class Solution:
    solution_dict: Dict[str, cs.DM]
    success: bool

    def get_model_solution_state(self, name, t):
         return self.solution_dict[f{name}/q'][:, t]

    def interpolate(self, name, duration):
        pass  # todo

This would be a little re-work but I think it would help optas become more extensible. I think this would be worthwhile. @joaomoura24, if this means a lot of hassle you're end. We could still incorporate the feature but put a flag in the Solver class interface. E.g. we put a flag saying solution_return_type='dict' by default (and the return type is what it is currently), and if the user wants to get the solution as the Solution class (something like above) perhaps they put solution_return_type='soln_cls' or something. I prefer not to do this but happy to if it means a lot of work your end.

I've not been a fan of having to do solution[f'{self.name}/q'] all the time, and also solver.interpolate doesn't make so much sense so would be good to put that functionality in a place that makes more sense.

@cmower cmower added the enhancement New feature or request label Feb 16, 2023
@joaomoura24
Copy link
Collaborator

Yeah, i agree.
This month i am already packed so i would propose that we start a branch in March to add this.

If this has time and you are happy with it, I can start the branch directly in the repo (not sure about permission).

Additionally, I would suggest also to include the parameters used to solve the problem in the returned solution class, and the respective methods to access them by name. (whether they are model parameters or parameters defined by the user)

@cmower
Copy link
Owner Author

cmower commented Feb 16, 2023

Cool, will keep in mind.

I can do the main implementation. Then you can check out once it is done when ever you have time.

@cmower cmower added the future Plans for the future. label May 8, 2023
@cmower cmower added the help wanted Happy to accept pull requests label Aug 11, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request future Plans for the future. help wanted Happy to accept pull requests
Projects
None yet
Development

No branches or pull requests

2 participants