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 to AD component of quasi-static Finite-strain compressible elasticity #50

Draft
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

jppelteret
Copy link
Member

This modernises the AD data structures used in this code-gallery example.

@jppelteret jppelteret added the WIP label Jan 22, 2019
@jppelteret
Copy link
Member Author

Currently WIP because I would like to generalise this to all ad_type_codes that we support (i.e. enable ADOL-C support and choose the AD library in the parameter file).


template <int dim>
struct Assembler<dim,Sacado::Fad::DFad<double> > : Assembler_Base<dim,Sacado::Fad::DFad<double> >
{
typedef Sacado::Fad::DFad<double> ADNumberType;
using ADHelper = AD::ADHelperResidualLinearization<AD::NumberTypes::sacado_dfad,double>;
Copy link
Contributor

@davydden davydden Jan 22, 2019

Choose a reason for hiding this comment

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

I started applying this to the code derived from the code gallery and indeed, we certainly need a way to go from an arbitrary (AD) NumberType to the enumerator, and thus as you said, we need something like none for non-AD types.

EDIT: I think if works for current AD number types, that would actually already be enough, at least in my case, as far as I can tell. Let me se if I can add this tomorrow...

Copy link
Member Author

Choose a reason for hiding this comment

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

I actually like the idea of an AD::NumberTypes::None. It would have simplified some of my own code, so I think I'd still like to implement it. It shouldn't be too much work.

Copy link
Contributor

Choose a reason for hiding this comment

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

sure, I agree, it will be useful regardless. What I meant is that even without None the link from AD numbers to enumerators can help.

Copy link
Member Author

@jppelteret jppelteret Jan 23, 2019

Choose a reason for hiding this comment

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

For the record, Differentiation::AD::ADNumberTraits<ADNumberType>::type_code defines this backwards link.

Copy link
Contributor

Choose a reason for hiding this comment

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

nice 👍 Did not know about that. Thanks for the link.

@davydden
Copy link
Contributor

Currently WIP because I would like to generalise this to all ad_type_codes that we support (i.e. enable ADOL-C support and choose the AD library in the parameter file).

I played around and got the support for any AD numbers working (seems so at least) in my derived code using AD::NumberTraits::n_supported_derivative_levels. However this constraints the choice between residual and energy AD purely based upon n_supported_derivative_levels meaning one can't use adolc_taped for residual linearization. That's probably not how we should recommend using ADHelper, but that's how I got this setup for now. Just my 2c.

@jppelteret
Copy link
Member Author

However this constraints the choice between residual and energy AD purely based upon n_supported_derivative_levels meaning one can't use adolc_taped for residual linearization.

You could get around this with a more specific check, for example:

enable_if<ADNumberTraits::is_taped || (ADNumberTraits::is_tapeless && ADNumberTraits::n_supported_derivative_levels >= 2)>

I think that this should work in your case.

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

Successfully merging this pull request may close these issues.

2 participants