You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Problem. The checks cover nodes, links, their data and the model type, but there is no hook for checking resources themselves or the combination of an element with the resources it carries. A package introducing resources with parameters (voltage limits, numbers of linearisation segments) and with requirements on the elements carrying them (at most one such resource per node, impedance data matching the formulation on a transmission mode) can only check these through a package-level function the user has to call, because a method of check_node for RefSink would be type piracy.
Proposal. Two functions with empty defaults, called from the existing check loops:
# called from check_elements for every element and every resource family it carriescheck_resource(x::AbstractElement, 𝒫ˢᵘᵇ::Vector{<:Resource}, 𝒯, modeltype, check_timeprofiles) =nothing# called from check_data for every resource family of the case products, logged as "Resources"check_resources(𝒫ˢᵘᵇ::Vector{<:Resource}, 𝒯, modeltype, check_timeprofiles) =nothing
The logs of check_resource are attached to the element, those of check_resources to a new entry "Resources" in the consistency log. EnergyModelsGeography would call check_resource for areas and transmission modes in its check_elements methods as well.
Why non-breaking. Both defaults return nothing; the check loops gain one call each.
Tests. A test resource with a check_resources method that logs on a wrong parameter and a check_resource method that logs for a sink carrying it; the messages appear under the element and under "Resources".
Generally speaking, it is fine. However, the generic resources should be checked within check_case_data while the nodal/link specific check is, in my opinion, a bit more complicated regarding the location.
Do you see there checks that are related to the variables flow_in, flow_out, link_in, and link:_out, capacities as outlined in #105 or any other? approach? We have to be a bit careful here regarding method ambiguities so that we do not end up with making a mess for us...
called from check_case_data for every family in res_types_vec(get_products(case)).
No checks on flow_in, flow_out, link_in or link_out are foreseen; these are input-data checks. The capacity check of #105 stays with the node in check_elements.
Activity
JulStraus commentedon Oct 7, 2026
Generally speaking, it is fine. However, the generic resources should be checked within
check_case_datawhile the nodal/link specific check is, in my opinion, a bit more complicated regarding the location.Do you see there checks that are related to the variables
flow_in,flow_out,link_in, andlink:_out, capacities as outlined in #105 or any other? approach? We have to be a bit careful here regarding method ambiguities so that we do not end up with making a mess for us...espenbodal commentedon Oct 7, 2026
Agreed on
check_case_datafor the resource checks. I would also drop the element-level hook and keep a single case-level hook per resource family:called from
check_case_datafor every family inres_types_vec(get_products(case)).No checks on
flow_in,flow_out,link_inorlink_outare foreseen; these are input-data checks. The capacity check of #105 stays with the node incheck_elements.Apply review comments on check_resources (#107)