feat: Add support for non_parametric optimization #100
Conversation
tmpbeing
requested review from
yias,
awoimbee,
kliment-slice,
mmeisso and
romane-m
tmpbeing
force-pushed
the
feat/non_parametric_optimization
branch
from
50c09f3
to
2f6d909
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #100 +/- ##
==========================================
+ Coverage 83.54% 85.47% +1.93%
==========================================
Files 44 44
Lines 2576 2617 +41
==========================================
+ Hits 2152 2237 +85
+ Misses 424 380 -44 ☔ View full report in Codecov by Sentry. |
| """ | ||
| geometry = get_object_from_identifiable(geometry, self._client._geometry_directory) | ||
| objective = _build_objective(minimize, maximize) | ||
| optimization_parameters = { |
There was a problem hiding this comment.
since optimization parameters is used both in run_parametric and run_non_parametric with small differences, it might deserve to have a function or class for its construction, according to parametric or non-parametric. Maye it would save some a few lines of code too 😄
| if trial_run.fields.get("is_feasible", True): | ||
| iterations_results.append(iteration_result) | ||
| else: | ||
| logger.debug("Trial run results did not match constraints. Skipping.") |
There was a problem hiding this comment.
I guess this is something not important for the user, and it doesn't need to be notified.
There was a problem hiding this comment.
Which is why it's in debug level. Most users won't ever see log from the SDK, you have to specifically enable them, even more so when it's debug.
| for _ in range(n_iters): | ||
| logger.debug("Running iteration") | ||
| progress_bar.set_description("Running iteration") | ||
| trial_run = optimization._run_iteration({}) |
There was a problem hiding this comment.
This {} arg could really use a validation with a raise InvalidArguments
| optimization: Identifiable[Optimization], | ||
| geometry: Identifiable[Geometry], | ||
| geometry_parameters: Dict, | ||
| def _run_iteration( |
There was a problem hiding this comment.
nit: same method name for both optim and optimtrialrun objects, but with different args..
| self, | ||
| geometry: Identifiable[Geometry], | ||
| bounding_boxes: List[List[float]], | ||
| symmetries: List[Literal["x", "y", "z", "X", "Y", "Z"]], |
There was a problem hiding this comment.
I think the value of typing for both upper and lower case is not worth it compared to "Hugh ? Why am I seeing double ?"
There was a problem hiding this comment.
Since I could not wrap my head around the interaction of the different components I made this:
sequenceDiagram
participant User
participant OptDir as OptimizationDirectory
participant TrialDir as OptimizationTrialRunDirectory
User ->> OptDir: run_parametric
activate User
activate OptDir
create participant Opti as Optimization
OptDir -x Opti: creates
loop Until optimization complete
OptDir->>Opti: _run_iteration
activate Opti
Opti->>TrialDir: _run_iteration
activate TrialDir
create participant Trial as OptimizationTrialRun
TrialDir-xTrial: Creates
activate Trial
TrialDir-->>Opti: returns OptimizationTrialRun
deactivate TrialDir
Opti-->>OptDir: returns OptimizationTrialRun
deactivate Opti
OptDir->>Trial: Get iteration results
deactivate Trial
end
deactivate OptDir
OptDir-->>User: result (List[Dict])
deactivate User
Conclusions:
- Some objects are not meant to be handled by end users (OptimizationTrialRun and OptimizationTrialRunDirectory so should be prefixed by "_")
- The relationships between objects must be better defined in the code, even in the definition order, define the children first:
OptimizationTrialRunthenOptimizationTrialRunDirectorythenOptimizationthenOptimizationDirectory - Maybe
_run_iterationshould only be defined on theOptimization? - I don't understand what
OptimizationTrialRunDirectory.getcould be used for
No description provided.