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

ConstantValue and Parameter #267

Open
mscroggs opened this issue Apr 18, 2024 · 3 comments
Open

ConstantValue and Parameter #267

mscroggs opened this issue Apr 18, 2024 · 3 comments

Comments

@mscroggs
Copy link
Member

As discussed at SysGenX meeting, we should:

  • Rename ConstantValue to AbstractParameter. This is the base class for parameters (previously constants) without a domain
  • Add Parameter class that inherits from AbstractParameter to represent a parameter with an unknown value
  • Leave Constant as it is: representing a constant over a domain
@jorgensd
Copy link
Member

Is Firedrake (or FEniCSx for that matter) using ConstantValue?
As discussed earlier, Constant with an associated domain is motivated by differentiation (i.e. the derivative of a Constant-value maps to the real-element).

@dham
Copy link
Collaborator

dham commented Apr 18, 2024

Yes, we are using ConstantValue. As soon as you start doing multiple domain calculations, having to associate a domain with a constant is a pain. We concede the differentiation point. For the moment, differentiation WRT to a Parameter won't be possible. In theory in the future it could be made so but that is a much bigger change.

@jorgensd
Copy link
Member

I think AbstractParameter should have a dtype as input, as it could be:
Float32,float64,complex64, complex128 etc, which should change the representation of it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: No status
Development

No branches or pull requests

3 participants