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

AD Strong DG - Implicit Inviscid - Computes Jacobians #261

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

Conversation

AlexanderCicchino
Copy link
Collaborator

@AlexanderCicchino AlexanderCicchino commented Jun 27, 2024

Strong DG now uses AD to compute Jacobians for dR/du and dR/dX for pdes that don't have diffusion. Implicit strong DG implemented for convective pdes. Operators templated.

Implementation Changes:
-Operators: removed the real template and instead templated the function calls, like matrix_vector_mult. This change was made because the class doesn't need to know the template since the basis functions are double, and the template only needs to be used when the operator is applied on a vector.
-DG Structure: The tape was pulled out of the functions in DGWeak into DGBase. The tape is defined in assemble_cell_residual_and_ad_derivatives, with sensitivities computed in assemble_volume_codi_taped_derivatives_ad, and face and boundary terms. For DGStrong, we reuse the metric terms from the interior cell on the face, so we set the tape position and compute the terms before the volume residual call in build_volume_metric_operators.
-DGStrong/Weak: The functions left are the residual evaluations, which are templated by real2 in DGWeak or adtype in DGStrong.
-Small changes: dealii::FullMatrix doesn't accept an AD argument so I changed the structure for the Hadamard products etc in DGStrong to use an std:::vector.

PranshulThakur and others added 30 commits May 17, 2024 17:28
…tions using vectors instead of dealii::FullMatrix because FullMatrix cannot use AD variables.
…utes Jacobian DRDX and DRDW. Have it passing selected previous ctests.
… the regression unit tests for advection and the implicit solve for Euler Gaussian bump with an entorpy stable scheme.
@AlexanderCicchino AlexanderCicchino marked this pull request as draft June 27, 2024 17:18
@AlexanderCicchino
Copy link
Collaborator Author

Currently running full ctest and will post log file when it is completed.

@AlexanderCicchino
Copy link
Collaborator Author

Added finite difference vs Ad Jacobian unit tests. dR/dU works/validated, but dR/dX does not pass for strong currently.

@AlexanderCicchino
Copy link
Collaborator Author

dR/dX works now for dg strong and added sensitivity unit tests verifying. Also added unit tests for d2R

@AlexanderCicchino AlexanderCicchino changed the title AD Strong DG - Computes Jacobians AD Strong DG - Implicit Inviscid - Computes Jacobians Jun 27, 2024
@AlexanderCicchino AlexanderCicchino marked this pull request as ready for review June 27, 2024 21:17
@PranshulThakur
Copy link
Collaborator

dR/dX works now for dg strong and added sensitivity unit tests verifying. Also added unit tests for d2R

Thanks @AlexanderCicchino . The current PR of computing sensitivities with strong DG will facilitate several future avenues for research. There is currently an issue on narval with cmake when compiling master and is not specific to this PR. I will post the results of running ctest on narval soon once the issue is fixed.

@cpethrick
Copy link
Collaborator

I just tried compiling in debug mode and there are some issues with the Assert statements and it doesn't build. Commenting so that the issue is recorded!

Thanks for the description of the implementation changes, @AlexanderCicchino, they are quite helpful :)

@AlexanderCicchino
Copy link
Collaborator Author

I just tried compiling in debug mode and there are some issues with the Assert statements and it doesn't build. Commenting so that the issue is recorded!

Thanks for the description of the implementation changes, @AlexanderCicchino, they are quite helpful :)

Fixed the debug mode Assert issues.

Copy link
Collaborator

@cpethrick cpethrick left a comment

Choose a reason for hiding this comment

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

I've done one pass over the PR. It seems like a tremendous amount of work and I'm glad to see it working! I've left a few comments and questions. AD is not a familiar topic for me so my comments are mainly about readability. I can go through it again in more detail if needed.

for(int idim=0; idim<dim; idim++){
rhs_aux[idim][current_dofs_indices[i]] += current_cell_rhs_aux[i][idim];
for(int idim=0; idim<dim; idim++){
for (unsigned int i=0; i<n_dofs_curr_cell; ++i) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

maybe idof would be more consistent with other loops in DG?

Copy link
Collaborator

Choose a reason for hiding this comment

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

or itest

dealii::Tensor<1,dim,std::vector<real>> current_cell_rhs_aux;// Defaults to 0.0 initialization
if(compute_auxiliary_right_hand_side){
for(int idim=0; idim<dim; idim++){
current_cell_rhs_aux[idim].resize(n_dofs_curr_cell);
Copy link
Collaborator

Choose a reason for hiding this comment

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

Did the old implementation allocate rhs_aux for any PDE, even ones without dissipation? I.e., does this version have a lower memory use for inviscid PDEs?

for (unsigned int itest_int=0; itest_int<n_soln_dofs_int; ++itest_int) {
current_cell_rhs_aux[idim][itest_int] += getValue<adtype>(aux_rhs_int[idim][itest_int]);
}
// for (unsigned int itest_ext=0; itest_ext<n_soln_dofs_ext; ++itest_ext) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Commented code

x_end = x_start + n_metric_dofs;
w_start = x_end;
w_end = w_start + 0;
} //else {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Commented code (also in the next function)

const bool compute_auxiliary_right_hand_side,//flag on whether computing the Auxiliary variable's equations' residuals
dealii::LinearAlgebra::distributed::Vector<double> &rhs,
std::array<dealii::LinearAlgebra::distributed::Vector<double>,dim> &rhs_aux);

template <typename adtype>
Copy link
Collaborator

Choose a reason for hiding this comment

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

Can you add comments about this function and following ones?

const unsigned int ishape = this->fe_collection[poly_degree].system_to_component_index(idof).second;
if(ishape == 0)
soln_coeff[istate].resize(n_shape_fns);
soln_coeff[istate][ishape] = soln_coeffs[idof];
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
soln_coeff[istate][ishape] = soln_coeffs[idof];
soln_coeff[istate][ishape] = soln_coeffs[idof];

soln_coeff[istate][ishape] = soln_coeffs[idof];
for(int idim=0; idim<dim; idim++){
if(ishape == 0)
aux_soln_coeff[istate][idim].resize(n_shape_fns);
Copy link
Collaborator

Choose a reason for hiding this comment

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

Does this need to be done in inviscid cases?

typename dealii::DoFHandler<dim>::active_cell_iterator /*cell*/,
adtype &dual_dot_residual);

void assemble_volume_term_and_build_operators_ad(
Copy link
Collaborator

Choose a reason for hiding this comment

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

Add documentation to several functions in this header

Copy link
Collaborator

Choose a reason for hiding this comment

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

Maybe highlight the difference between the similar functions when adding comments? I see that these take different types as arguments. It would be a bit easier to read if these are written explicitly in the documentation :)

Copy link
Collaborator

Choose a reason for hiding this comment

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

Is it possible to use the same code for strong and weak? I see that this code is very similar to d2RdWdW_fd_vs_ad.cpp. Could you either unify these tests and have the same test run twice (once for strong, once for weak), or have an input variable/PRM file?

If it's too much work to unify, it's also okay to leave as-is.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Could you add "_weak" to the names of the old sensitivity tests? I would also prefer that they use upper-case letters to be consistent with other tests, though I understand that the current naming was chosen for consistency with the old tests.

@PranshulThakur PranshulThakur marked this pull request as draft November 21, 2024 21:44
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.

3 participants