Skip to content

Initial lambda extraction - #566

Open
lukelowry wants to merge 4 commits into
developfrom
lukel/lambda-dev
Open

Initial lambda extraction#566
lukelowry wants to merge 4 commits into
developfrom
lukel/lambda-dev

Conversation

@lukelowry

Copy link
Copy Markdown
Collaborator

Description

Extract the inconsistent lambdas for parameter validation and signal attachment into one common layer

Proposed changes

  • Utilities::ConfigurationCheck
  • Utilities::ParameterReader

Checklist

  • All tests pass.
  • Code compiles cleanly with flags -Wall -Wpedantic -Wconversion -Wextra.
  • The new code follows GridKit™ style guidelines.
  • There are unit tests for the new code.
  • The new code is documented.
  • The feature branch is rebased with respect to the target branch.
  • NA The CHANGELOG.md has been updated to reflect the changes. If this is a minor PR that is part of a larger fix already included in the file, state so.

Further comments

@nkoukpaizan Drafted until you take a quick look, is this good approach generally?

@nkoukpaizan nkoukpaizan added the enhancement New feature or request label Sep 3, 2026
@lukelowry
lukelowry force-pushed the lukel/lambda-dev branch 3 times, most recently from 8523e16 to 1c5cb77 Compare September 9, 2026 20:19
@lukelowry
lukelowry marked this pull request as ready for review September 10, 2026 00:11
@lukelowry

Copy link
Copy Markdown
Collaborator Author

I am marking this as ready for review, so that we can determine remaining priorities before release.

Let me know if this is worth it before release

@nkoukpaizan nkoukpaizan left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the idea of extracting the lambda. What we need to discuss is where the extracted methods will live.

std::unique_ptr<MonitorT> monitor_;

/// Count of parameter-loading errors reported through verify()
IdxT parameter_error_count_{0};

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wouldn't think we need to store this as a member variable. Removing would also avoid the static_cast<int>.

Comment on lines +232 to +244
template <ExternalVariables variable>
auto refreshWorkspace(ScalarT fallback, ScalarT* ws, IdxT* ws_indices) const
{
static_assert(variable < ExternalVariables::MAXIMUM);
const auto index = static_cast<size_t>(variable);
ws[index] = fallback;
ws_indices[index] = INVALID_INDEX<IdxT>;
if (isAttached<variable>())
{
ws[index] = readExternalVariable<variable>();
ws_indices[index] = readExternalVariableIndex<variable>();
}
}

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wouldn't make ComponentSignals depend on ws_. Let's keep these in *Impl.hpp.

Comment on lines +251 to +284
template <ExternalVariables variable>
auto checkRequired(Utilities::ConfigurationChecks& checks, const char* name) const
{
static_assert(variable < ExternalVariables::MAXIMUM);
if (!isAttached<variable>())
{
checks.fail() << name << " signal is required\n";
return;
}
if (!isLinked<variable>())
{
checks.fail() << name << " signal attached with no linked source\n";
}
}

/// Verifies a port that may be absent but must resolve to linked
/// storage when attached
///
/// @tparam variable The external variable to verify
/// @param[in,out] checks Error accumulator for the owning component
/// @param[in] name Port name used in error messages
template <ExternalVariables variable>
auto checkOptional(Utilities::ConfigurationChecks& checks, const char* name) const
{
static_assert(variable < ExternalVariables::MAXIMUM);
if (!isAttached<variable>())
{
return;
}
if (!isLinked<variable>())
{
checks.fail() << name << " signal attached with no linked source\n";
}
}

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's not make ComponentSignals depend on ConfigurationChecks. Let's keep these in *Impl.hpp.

/**
* @file ConfigurationChecks.hpp
* @author Luke Lowery (lukel@tamu.edu)
* @brief Error accumulator for model configuration validation.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Documentation will need an update.

* the `Parameters` enumeration, and the `parameters` map.
*/
template <typename ModelDataT>
class ParameterReader

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The methods look good to me. I'd like to get thoughts from @PhilipFackler and @superwhiskers on where these should live. I think it should be in GridKit/Model/.

@superwhiskers superwhiskers left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

some quick comments. overall seems like a good change to make

* @tparam ModelDataT A model data container exposing `RealT`, `IdxT`,
* the `Parameters` enumeration, and the `parameters` map.
*/
template <typename ModelDataT>

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

note: if/when #570 is merged, should probably require the ModelData concept present in GridKit/Model/PhasorDynamics/ModelData.hpp

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you should be able to do this now

/// Log one error against this model and count it.
std::ostream& fail()
{
++error_count_;

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i still think we should move away from counting errors and toward something more robust

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants