feat: Add support for non_parametric optimization

[tmpbeing]

No description provided.

[codecov]

Codecov Report

Attention: Patch coverage is 86.95652% with 9 lines in your changes missing coverage. Please review.

Project coverage is 85.55%. Comparing base (167e38a) to head (c93de56).
Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
src/ansys/simai/core/data/optimizations.py	86.56%	9 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #100      +/-   ##
==========================================
+ Coverage   83.62%   85.55%   +1.92%     
==========================================
  Files          44       44              
  Lines        2589     2630      +41     
==========================================
+ Hits         2165     2250      +85     
+ Misses        424      380      -44     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[yias]

It looks fine. I just have a few comments.

I'm also wondering if a run_parametric and run_non_parametric could be a separated dataclass/pydantic class with fields and validators for avoiding having all the functions classified as internally used (_)

[yias]

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 😄

[kliment-slice]

This {} arg could really use a validation with a raise InvalidArguments

[kliment-slice]

nit: same method name for both optim and optimtrialrun objects, but with different args..

[awoimbee]

Generally nice but data/optimizations.py is hard to understand

[awoimbee]

I think the value of typing for both upper and lower case is not worth it compared to "Hugh ? Why am I seeing double ?"

[awoimbee]

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

Loading

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: OptimizationTrialRun then OptimizationTrialRunDirectory then Optimization then OptimizationDirectory
• Maybe _run_iteration should only be defined on the Optimization ?
• I don't understand what OptimizationTrialRunDirectory.get could be used for