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

Update tutorial to use ADMaterialProperty in consumers #13948

Merged
merged 1 commit into from
Aug 22, 2019

Conversation

lindsayad
Copy link
Member

This was reported by a user here

We happen to know here that the producer of the _permeability is not using any non-linear variables in its calculation, but we want to teach our users that in their AD consumer objects they should (almost) always use ADMaterialProperty. It is consistent with our modular philosophy because who knows if sometime in the future we want to change the _permeability to be calculated based on non-linear variables.

@moosebuild
Copy link
Contributor

moosebuild commented Aug 21, 2019

Job Documentation on 3354045 wanted to post the following:

View the site here

This comment will be updated on new commits.

@tophmatthews
Copy link
Contributor

When is the case where you don't want to use ADMaterialProperty? Isn't there memory overhead? If there isn't, why not just make all materials AD?

@aeslaughter
Copy link
Contributor

So, I made this part of the tutorial as such exactly for the reason of showing and explaining the difference between the two. I don't really want to get rid of it unless we are actually going to deprecate the non-AD version.

@lindsayad
Copy link
Member Author

When is the case where you don't want to use ADMaterialProperty? Isn't there memory overhead? If there isn't, why not just make all materials AD?

After #12599 I believe the memory expense incurred by AD is not all that high. The greatest memory expense for materials occurs when we have stateful material properties. After #12599, there is still an additional memory cost to having AD, but it's only 17 bytes to 8 bytes. Moreover, this expense is actually incurred no matter what. All material properties are created as AD material properties behind the scenes. It has to be this way to preserve inter-operability between non-AD and AD objects. Which brings us to...

So, I made this part of the tutorial as such exactly for the reason of showing and explaining the difference between the two. I don't really want to get rid of it unless we are actually going to deprecate the non-AD version.

This is perfectly mine with me. So perhaps instead I'll just put some doxygen comments inside the header to explain why we have the difference here.

@lindsayad
Copy link
Member Author

When is the case where you don't want to use ADMaterialProperty? Isn't there memory overhead? If there isn't, why not just make all materials AD?

There is CPU expense. The expense of computing a DualNumber*DualNumber vs. a double*DualNumber is twice as large. However, depending on what you care about, this may mean less to you than increased modularity. However, obviously there's a time and place to care about speed! That's perhaps the number one reason why hand-coded materials may stay around for a long time. @friedmud achieved faster Jacobian computation using AD vs hand-coded in his Julia code, so maybe we can get there some-day. Certainly roystgnr/MetaPhysicL#53 will give us greatly increased AD flexibility, but it does not speed up existing AD simulations

@tophmatthews
Copy link
Contributor

I'm all for AD. It has really changed the game for my work. It's good to know to just make EVERYthing an AD material.

@tophmatthews
Copy link
Contributor

And automatic scaling...that should be automatically turned on it kicks so much ass!!!!!

@lindsayad
Copy link
Member Author

lindsayad commented Aug 22, 2019 via email

@hugary1995
Copy link
Contributor

Wow! Do you know the reason for AD being faster than hand-coded Jacobian in Julia?

@tophmatthews
Copy link
Contributor

Yeah, AD and AS made an unsolvable problem solvable with thermo-mechanics. At first I couldn't understand why it wasn't running any nonlinear iterations, and I thought it was doing worse. Turns out my tolerances were so loose to get anything to work before that it wasn't even taking a single iteration. Once I cranked them down, it flew by the difficult spots.

@lindsayad
Copy link
Member Author

lindsayad commented Aug 22, 2019 via email

@aeslaughter aeslaughter merged commit d0a1e40 into idaholab:next Aug 22, 2019
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

Successfully merging this pull request may close these issues.

5 participants