Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Friction values supplied by user are ignored when using setup_channels #111

Closed
2 tasks done
rvnooyen opened this issue Nov 5, 2023 · 3 comments
Closed
2 tasks done
Labels
bug Something isn't working

Comments

@rvnooyen
Copy link

rvnooyen commented Nov 5, 2023

Version checks

  • I have checked that this issue has not already been reported.
  • I have checked that this bug exists on the latest version.

Reproducible Example

The method dflowfm.setup_channels in dflowfm.py specifies

"friction_type",
"friction_value",

as allowed columns, so frictiontype and frictionvalue will be dropped silently. The routine crosssections::prepare_default_friction_and_crosssection then sets

defaults["frictiontype"] = friction_type
defaults["frictionvalue"] = friction_value

from the function parameters and at line 99 update_data_columns_attributes then adds columns "frictiontype" and "frictionvalue" which results in two different specifications. In file crosssections.py the routine set_point_crosssections passes only the fields "frictiontype" and "frictionvalue" from the frame branches on to be merged into the user supplied cross sections.

Current behaviour

Friction values supplied by user are ignored when using setup_channels

Desired behaviour

Friction values supplied by user passed on to model when using setup_channels

Additional context

No response

@rvnooyen rvnooyen added the bug Something isn't working label Nov 5, 2023
@veenstrajelmer
Copy link
Collaborator

veenstrajelmer commented Sep 23, 2024

This might be because FMModel.physics.UniFrictType was called instead of FMModel.physics.uniffricttype (mind the casing and the extra f in the keyword). This will be resolved in #139

@shartgring
Copy link
Collaborator

Should be fixed now!

@veenstrajelmer
Copy link
Collaborator

After reading the issue description again, I am not sure if the PR I mentioned solved the issue. Do you think it does?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants