Config file for complex modeling artifacts conversion

[aoustry]

This is a V1 for a configuration file structure to parametrize a future functionality of the Antares-to-Andromede converter... here in the particular case of the Antares "battery model".

There are still some "todos" :

• design question: how to smartly refer to parameters of Antares's object (eg : pmax of a cluster, capacity of a link), so that it is easily manageable by the input_converter code ? @tbittar : an idea of id?
• design question: how to manage time/scenario-dependant parameters
• "battery model" case: manage the initial stock level, guiding curves, and modulation.

[tbittar]

Suggested change

	iteration_key: zone #Key on which we iterate (for a given list of zone, we want to execute a loop : for zone in list_zone)
	iteration_key: area #Key on which we iterate (for a given list of zone, we want to execute a loop : for zone in list_zone)

[tbittar]

Suggested change

	andromede-component-id : battery_$zone$
	andromede-component-id : battery_$area$

[tbittar]

Suggested change

	#- id: lower_rule_curve
	#- id: upper_rule_curve

[tbittar]

Does the current modelling of batteries with the binding constraints define lower/upper rule curves (maybe implicitly ?) ? Otherwise set lower_rule_curve to 0 and upper-rule-curve to 1

[tbittar]

Do you think it is better to write a specialized short term storage models for batteries or we can keep the current one ? And usually the initial_level is at 0.5 ? Otherwise it may be optimized, in this case, we definitely need a different model

[tbittar]

Could this be read from the availability series of thermal clusters in z_batteries ? Or the link profile between the physical area and z_batteries ?

[tbittar]

What do you mean by hybrid mode here ?

[tbittar]

Suggested change

	location-in-legacy-study: link_capacity #TODO : find the right id to describe link capacity? @tbittar
	location-in-legacy-study: input/links/$zone$/capacities/$zone$_direct.txt

[tbittar]

Suggested change

	location-in-legacy-study: p_max_cluster #TODO : find the right id to describe cluster pmax? @tbittar
	location-in-legacy-study: input/thermal/series/$zone$/$zone$_batteries_inj/series.txt

[tbittar]

Suggested change

	location-in-legacy-study: p_max_cluster #TODO : find the right id to describe cluster pmax? @tbittar
	location-in-legacy-study: input/thermal/series/z_batteries/z_batteries_batteries_$zone$_1/series.txt

[tbittar]

Why "hybrid" ?

[tbittar]

Instead of giving the Antares components to iterate through, we could specify directly the location of the Andromede model parameters :

Suggested change

	antares-coupling-constraints-to-visit:
	- id : batteries_$zone$
	name: batteries_$zone$
	to-delete: True #This flag means that the constraint should be deleted from the Antares Study, if hybrid mode is targetted
	parameters-to-store:
	- id-target-andromede-model-parameter: efficiency_injection #target parameter in the andromede-model
	location-in-legacy-study: $zone$%z_batteries #where to read the parameter in the Antares coupling constraint
	multiplication-factor: -1 # The parameter we read in Antares coupling constraint should be multiplied by -1 to create target param
	- id-target-andromede-model-parameter: efficiency_withdrawal #there are different naming conventions between Antares CC model for batteries and the short-term storage model
	#=> therefore there is an intervertion between injection and withdrawal (this is no mistake)
	location-in-legacy-study: $zone$.$zone$_batteries_inj
	multiplication-factor: 1
	- id: efficicency_injection
	time-dependent: false
	scenario-dependent: false
	value: batteries_$zone$::$zone$%z_batteries
	multiplication_factor: -1
	- id: efficicency_withdrawal
	time-dependent: false
	scenario-dependent: false
	value: batteries_$zone$::$zone$.$zone$_batteries_inj

And add a field a the end to list the legacy components to delete

[aoustry]

@tbittar : I took your comments into account in a V2 file : src/andromede/input_converter/src/cc_configuration/batteries_v2.yaml

[tbittar]

Delete batteries.yaml which is now useless and rename batteries_v2 as batteries

[tbittar]

Generated with AI :

Let me analyze the YAML configuration file and suggest some improvements, particularly focusing on the structure and consistency of the value fields.

Inconsistent Value Field Structure

• The value field has different structures across parameters, which can make it confusing and harder to maintain. For example:
• Some use a list of key-value pairs (like reservoir_capacity)
• Some use a dictionary with path and column (like injection_nominal_capacity)
• Some use a dictionary with binding_constraint and field (like efficiency_injection)
• Some use a simple scalar value (like lower_rule_curve)

Suggested Improvements

1. Consistent Value Structure

• Each value field now has a consistent structure with two main fields:
• type: Indicates the type of value (file, cluster, binding_constraint, constant)
• data: Contains the actual data specific to that type

2. Better Type Safety

• The type field makes it explicit what kind of data we're dealing with
• Each type has its own specific data structure, making it easier to validate

3. Cleaner References

• Instead of using division operations in multiplication factors (like 1.0 /reservoir_capacity), I've introduced a reference field
• This makes it clearer that we're referencing another parameter

4. Removed Inline Comments

• Moved comments to be more structured and part of the data model
• This makes the YAML cleaner and more maintainable

5. Consistent Naming

• Standardized field names (e.g., constraint instead of binding_constraint)
• Made the structure more predictable

The new structure has several benefits:

• It's more self-documenting
• It's easier to validate
• It's more maintainable
• It's easier to extend with new types of values
• It's more consistent with modern YAML best practices

Human analysis : Some of these comments (but not all), may be relevant to take into account (in particular consistency accross all value files)

[killian-scalian]

Ok for me