Add classes to handle profiling of Payu configurations.

[micaeljtoliveira]

No description provided.

[micaeljtoliveira]

@manodeep @edoyango Here is the code I've been working on. Currently marked as draft and still missing tests, but would be good to have some feedback early on.

[micaeljtoliveira]

@edoyango @manodeep This is ready for review.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.00%. Comparing base (580517e) to head (be1b051).
⚠️ Report is 5 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff            @@
##              main       #13   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           10        13    +3     
  Lines          345       443   +98     
=========================================
+ Hits           345       443   +98     

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

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[edoyango]

I think it looks good! My only optional suggestion is that instead of *ConfigProfiling use ModelConfigProfiling or ModelProfiling. Just because ConfigProfiling sounds like it could be configuration utilities for the profiling package (at least, that's where my mind went to before looking at the code). May also want to rename config_profiling.py for similar reasons.

So, similar to how PayuConfigProfiling is a child of ConfigProfiling and ESM16ConfigProfiling is a child of PayuConfigProfiling, would we also have a CylcConfigProfiling, which is a child of ConfigProfiling, and a rAM3ConfigProfiling which is a child of CylcConfigProfiling?

[micaeljtoliveira]

@edoyango Thanks for looking at the code!

I think it looks good! My only optional suggestion is that instead of *ConfigProfiling use ModelConfigProfiling or ModelProfiling. Just because ConfigProfiling sounds like it could be configuration utilities for the profiling package (at least, that's where my mind went to before looking at the code). May also want to rename config_profiling.py for similar reasons.

I'll try to think of better names, but will wait for Manodeep's feedback before implementing any changes.

So, similar to how PayuConfigProfiling is a child of ConfigProfiling and ESM16ConfigProfiling is a child of PayuConfigProfiling, would we also have a CylcConfigProfiling, which is a child of ConfigProfiling, and a rAM3ConfigProfiling which is a child of CylcConfigProfiling?

Yes, that's currently the idea.

[manodeep]

Made a few comments.

I am also not sure about the naming - for example, test_access_configs.py and test_config_profiling.py. Perhaps model is a better candidate

[manodeep]

ESM1.6 has both AMIP and PI - this one is targeting PI. Do we want to add the functionality for parsing AMIP?

(The jobname will change from access-esm1.6 to amip - but there are no MOM logs to parse for AMIP anyway)

[micaeljtoliveira]

If we change the way how we get the job name, then, from the point of view of the profiling data parsing, it should work for both configs, because missing MOM logs are simply ignored. So I would leave it as is for now and wait until the layout generators are integrated into these class to revisit this question.

[micaeljtoliveira]

@manodeep @edoyango I've now renamed the classes:

• ConfigProfiling -> ProfilingManager
• PayuConfigProfiling -> PayuManager
• ESM16ConfigProfiling -> ESM16Profiling

I also renamed the files:

• profiling/config_profiling.py -> profiling/manager.py
• profiling/payu_config.py -> profiling/payu_manager.py
• profiling/access_configs.py -> profiling/access_models.py
  (plus the corresponding tests).

Let me know what you think.