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

DEDataArray factorization overloads cause type ambiguity errors #648

Open
bgroenks96 opened this issue Mar 9, 2021 · 7 comments
Open

DEDataArray factorization overloads cause type ambiguity errors #648

bgroenks96 opened this issue Mar 9, 2021 · 7 comments

Comments

@bgroenks96
Copy link
Contributor

I'm not sure if this is intended or not, but it appears that the existing DEDataArray factorization overloads cause type ambiguity errors for stiff solvers, e.g:

LinearAlgebra.ldiv!(F::Factorization, B::DEDataArray) = ldiv!(F, B.x)

causes a type ambiguity error with the the LU factorization methods in LinearAlgebra because DEDataArray is more specific than AbstractArray but Factorization is less specific than LU.

This forces the user to define their own more specific method to resolve the ambiguity, which kind of seems to nullify the point of providing this method in the first place...?

Shouldn't these functions "just work" without these ambiguous overloads since DEDataArray is already an AbstractArray?

@ChrisRackauckas
Copy link
Member

This is starting to go into bad news bears territory because linear algebra doesn't always respect the propagation of the non-array variables, so it might have different semantics than you want. This is actually why I think I'm going to deprecate DEDataArray.

@bgroenks96
Copy link
Contributor Author

You mean because of the distinction between DenseArray and AbstractArray? Or do you mean that it won't always copy things properly?

DEDataArray is kind of what solved my problem with having extra (non-integrated) state variables, so is there an alternative? Of course the user can still specify their own custom array type without DEDataArray but there's a lot of method overrides that are necessary.

@ChrisRackauckas
Copy link
Member

I mean it's undefined how to copy things through some operations. I just don't think that is good behavior to have. And it carries memory in ways that are not optimal. I think MTK is just going to be more efficient and have more clean semantics in all but a very few cases.

@bgroenks96
Copy link
Contributor Author

But doesn't MTK turn everything into an ODEProblem in the end? Seems like you would still have this problem.

I experimented with MTK early on and it seemed like it wasn't really able to do this (i.e. have non-integrated state).

@ChrisRackauckas
Copy link
Member

It now has a whole observables system. MTK is a very fast moving project.

@bgroenks96
Copy link
Contributor Author

But can an integrated variable then depend on an observable?

@ChrisRackauckas
Copy link
Member

Yes. You can't effect it in an affect! though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants