Member GRINS::AntiochChemistry::AntiochChemistry (libMesh::UniquePtr< Antioch::ChemicalMixture< libMesh::Real > > &chem_mixture)

Use std::move when we have C++11

Member GRINS::AntiochConstantTransportMixture< KineticsThermoCurveFit, Conductivity >::_mu

Template on viscosity model, as we did for conductivity, to support parsed versions.

Member GRINS::AntiochConstantTransportMixture< KineticsThermoCurveFit, Conductivity >::AntiochConstantTransportMixture (libMesh::UniquePtr< Antioch::ChemicalMixture< libMesh::Real > > &chem_mixture, libMesh::UniquePtr< Antioch::ReactionSet< libMesh::Real > > &reaction_set, libMesh::UniquePtr< Antioch::NASAThermoMixture< libMesh::Real, KineticsThermoCurveFit > > &nasa_mixture, libMesh::UniquePtr< ConstantViscosity > &visc, libMesh::UniquePtr< Conductivity > &cond, libMesh::UniquePtr< Antioch::ConstantLewisDiffusivity< libMesh::Real > > &diff, libMesh::Real min_T=-std::numeric_limits< libMesh::Real >::max(), bool clip_negative_rho=false)

Use std::move() when we have C++11

Member GRINS::AntiochMixture< KineticsThermoCurveFit >::AntiochMixture (libMesh::UniquePtr< Antioch::ChemicalMixture< libMesh::Real > > &chem_mixture, libMesh::UniquePtr< Antioch::ReactionSet< libMesh::Real > > &reaction_set, libMesh::UniquePtr< Antioch::NASAThermoMixture< libMesh::Real, KineticsThermoCurveFit > > &nasa_mixture, libMesh::Real min_T=-std::numeric_limits< libMesh::Real >::max(), bool clip_negative_rho=false)

Use std::move when we have C++11

Member GRINS::AxisymmetricHeatTransfer< Conductivity >::_Cp

Need to generalize material parameters.

Shouldn't this rho be the same as the one in the flow? Need to figure out how to have those shared

Member GRINS::AxisymmetricHeatTransfer< Conductivity >::_Cp

Need to generalize material parameters.

Shouldn't this rho be the same as the one in the flow? Need to figure out how to have those shared

Member GRINS::CanteraKinetics::omega_dot (const libMesh::Real &T, const libMesh::Real rho, const std::vector< libMesh::Real > &mass_fractions, std::vector< libMesh::Real > &omega_dot) const

Need to make sure this will work in a threaded environment. Not sure if we will get thread lock here or not.

Member GRINS::CanteraThermodynamics::cp (const libMesh::Real &T, const libMesh::Real P, const std::vector< libMesh::Real > &Y)

Need to make sure this will work in a threaded environment. Not sure if we will get thread lock here or not.

Member GRINS::CanteraThermodynamics::cv (const libMesh::Real &T, const libMesh::Real P, const std::vector< libMesh::Real > &Y)

Need to make sure this will work in a threaded environment. Not sure if we will get thread lock here or not.

Member GRINS::CanteraTransport::k (const libMesh::Real &T, const libMesh::Real P, const std::vector< libMesh::Real > &Y)

Need to make sure this will work in a threaded environment. Not sure if we will get thread lock here or not.

Member GRINS::CanteraTransport::mu (const libMesh::Real &T, const libMesh::Real P, const std::vector< libMesh::Real > &Y)

Need to make sure this will work in a threaded environment. Not sure if we will get thread lock here or not.

Member GRINS::CanteraTransport::mu_and_k_and_D (const libMesh::Real T, const libMesh::Real rho, const libMesh::Real cp, const std::vector< libMesh::Real > &Y, libMesh::Real &mu, libMesh::Real &k, std::vector< libMesh::Real > &D)

Need to make sure this will work in a threaded environment. Not sure if we will get thread lock here or not.

Member GRINS::CatalyticWallBase< Chemistry >::_p0

make const

Member GRINS::CatalyticWallBase< Chemistry >::_species_vars

make const

Member GRINS::CatalyticWallBase< Chemistry >::_T_var

make const

Member GRINS::CatalyticWallNeumannBCFactoryBase< ImplType >::build_neumann_func (const GetPot &input, MultiphysicsSystem &system, const FEVariablesBase &fe_var, const std::string &section)

We're assuming constant thermodynamic pressure

Member GRINS::CatalyticWallNeumannBCOldStyleFactoryBase< ImplType >::build_neumann_func (const GetPot &input, MultiphysicsSystem &system, const FEVariablesBase &fe_var, const std::string &section)

We're assuming constant thermodynamic pressure

Member GRINS::ElasticityTensor::_C [3][3][3][3]

Does this guarantee continuous memory? If not, we should use a datastructure that does

Member GRINS::ElasticMembraneBase< StressStrainLaw >::init_variables (libMesh::FEMSystem *system)

Might want to make Order/FEType inputable

Member GRINS::GasRecombinationCatalyticWallNeumannBCFactoryImpl::build_catalytic_wall (const GetPot &input, const std::string &reaction, SharedPtr< CatalycityBase > &gamma_ptr, const std::vector< VariableIndex > &species_vars, const std::string &material, VariableIndex T_var, libMesh::Real p0, const std::string &thermochem_lib)

Update the API for the catalytic walls to take a unique_ptr to avoid this garbage.

Member GRINS::GasRecombinationCatalyticWallNeumannBCFactoryImpl::parse_reactant_and_product (const std::string &reaction, std::string &reactant, std::string &product) const

We currently can only handle reactions of the type R -> P e.g. not R1+R2 -> P, etc.

Member GRINS::GasSolidCatalyticWallNeumannBCFactoryImpl::build_catalytic_wall (const GetPot &input, const std::string &reaction, SharedPtr< CatalycityBase > &gamma_ptr, const std::vector< VariableIndex > &species_vars, const std::string &material, VariableIndex T_var, libMesh::Real p0, const std::string &thermochem_lib)

Update the API for the catalytic walls to take a unique_ptr to avoid this garbage.

Class GRINS::GRINSPrivate::VariableWarehouse

Currently, we only allow only unique variable types. This will change in the future once we allow per-subdomain variables. Hence, we have this in GRINSPrivate since the API may change in the future.

Member GRINS::HeatTransferBase< Conductivity >::_Cp

Need to generalize material parameters.

Shouldn't this rho be the same as the one in the flow? Need to figure out how to have those shared

Member GRINS::HeatTransferBase< Conductivity >::_Cp

Need to generalize material parameters.

Shouldn't this rho be the same as the one in the flow? Need to figure out how to have those shared

Member GRINS::HeatTransferBase< Conductivity >::_dim

Make this static member of base class?

Member GRINS::HookesLaw1D::HookesLaw1D (const GetPot &input, const std::string &material)

we'll need a special accessor to give ParameterUser access to these

Member GRINS::HookesLaw::HookesLaw (const GetPot &input, const std::string &material)

we'll need a special accessor to give ParameterUser access to these

Member GRINS::IncompressibleNavierStokes< Viscosity >::element_time_derivative (bool compute_jacobian, AssemblyContext &context)

Would it be better to put this in its own DoF loop and do the if check once?

Member GRINS::IncompressibleNavierStokesBase< Viscosity >::_rho

Create objects to allow for function specification

Member GRINS::IncompressibleNavierStokesStabilizationHelper::div_divU_I (libMesh::RealTensor &hess_u) const

Should we inline this?

Member GRINS::IncompressibleNavierStokesStabilizationHelper::div_divU_I (libMesh::RealTensor &hess_u, libMesh::RealTensor &hess_v, libMesh::RealTensor &hess_w) const

Should we inline this?

Member GRINS::IncompressibleNavierStokesStabilizationHelper::div_GradU (libMesh::RealTensor &hess_u) const

Should we inline this?

Member GRINS::IncompressibleNavierStokesStabilizationHelper::div_GradU (libMesh::RealTensor &hess_u, libMesh::RealTensor &hess_v, libMesh::RealTensor &hess_w) const

Should we inline this?

Member GRINS::IncompressibleNavierStokesStabilizationHelper::div_GradU_T (libMesh::RealTensor &hess_u) const

Should we inline this?

Member GRINS::IncompressibleNavierStokesStabilizationHelper::div_GradU_T (libMesh::RealTensor &hess_u, libMesh::RealTensor &hess_v, libMesh::RealTensor &hess_w) const

Should we inline this?

Member GRINS::IncompressibleNavierStokesStabilizationHelper::UdotGradU (libMesh::Gradient &U, libMesh::Gradient &grad_u, libMesh::Gradient &grad_v, libMesh::Gradient &grad_w) const

Should we inline this?

Member GRINS::IncompressibleNavierStokesStabilizationHelper::UdotGradU (libMesh::Gradient &U, libMesh::Gradient &grad_u) const

Should we inline this?

Member GRINS::IncompressibleNavierStokesStabilizationHelper::UdotGradU (libMesh::Gradient &U, libMesh::Gradient &grad_u, libMesh::Gradient &grad_v) const

Should we inline this?

Member GRINS::LowMachNavierStokesBase< Viscosity, SpecificHeat, ThermalConductivity >::_p0_var

When we mandate C++11, switch this to a SharedPtr.

Member GRINS::MaterialsParsing::parse_chemical_species (const GetPot &input, const std::string &material, std::vector< std::string > &species_names)

Make this prefix string an input option

Member GRINS::MeshAdaptivityOptions::parse_options (const GetPot &input, const std::string &section)

PB: why aren't parsing this?

Member GRINS::MeshBuilder::build (const GetPot &input, const libMesh::Parallel::Communicator &comm LIBMESH_CAN_DEFAULT_TO_COMMWORLD)

Can remove last 4 checks once mesh-options/mesh_option support is removed.

Need to a check a GMSH meshes

Member GRINS::MoleFractionsDirichletBCFactory::add_mole_frac_to_mass_frac (const GetPot &input, const std::string &section, const std::set< std::string > &vars_found, const std::string &material, const SpeciesMassFractionsVariable &species_fe_var, libMesh::CompositeFunction< libMesh::Number > &composite_func, std::set< std::string > &vars_added) const

We should have a ChemsitryWarehouse or something to just grab this from one place instead of rebuilding.

Member GRINS::MultiphysicsSystem::init_data ()

Figure out how to tell compilers not to fuse this loop when they want to be aggressive.

Member GRINS::MultiphysicsSystem::read_input_options (const GetPot &input)

Remove old print_residual nomenclature

Member GRINS::ParsedBoundaryQoI::side_qoi (AssemblyContext &context, const unsigned int qoi_index)

Need to generalize this to the multiple QoI case

Member GRINS::ParsedBoundaryQoI::side_qoi_derivative (AssemblyContext &context, const unsigned int qoi_index)

Need to generalize this to the multiple QoI case

Member GRINS::ParsedInteriorQoI::element_qoi (AssemblyContext &context, const unsigned int qoi_index)

Need to generalize this to the multiple QoI case

Member GRINS::ParsedInteriorQoI::element_qoi_derivative (AssemblyContext &context, const unsigned int qoi_index)

Need to generalize this to the multiple QoI case

Member GRINS::Physics::build_new_fe (const libMesh::Elem *elem, const libMesh::FEGenericBase< libMesh::Real > *fe, const libMesh::Point p)

This is straight up copied from libMesh. Need to make this available from libMesh.

Member GRINS::PostProcessedQuantities< NumericType >::init_context (const libMesh::FEMContext &context)

I believe this is redundant because it's done in the project_vector call. Double check.

Member GRINS::PrescribedMoleFractionsDirichletOldStyleBCFactory::convert_mole_fracs_and_add_to_func (const GetPot &input, const std::vector< libMesh::Number > &species_mole_fracs, const SpeciesMassFractionsVariable &species_fe_var, libMesh::CompositeFunction< libMesh::Number > &composite_func) const

We should have a ChemsitryWarehouse or something to just grab this from one place instead of rebuilding.

Member GRINS::PressurePinning::pin_value (libMesh::DiffContext &context, const bool request_jacobian, const GRINS::VariableIndex var, const double penalty=1.0)

pin_location needs to be const. Currently a libMesh restriction.

What the hell is the c.get_elem_solution_derivative() all about?

Member GRINS::QoIFactory::echo_qoi_list (SharedPtr< CompositeQoI > &qois)

Generalize to multiple QoI case when CompositeQoI is implemented in libMesh

Member GRINS::ReactingLowMachNavierStokes< Mixture, Evaluator >::compute_element_time_derivative_cache (AssemblyContext &context)

Need to figure out something smarter for controling species that go slightly negative.

Member GRINS::ReactingLowMachNavierStokes< Mixture, Evaluator >::element_time_derivative (bool compute_jacobian, AssemblyContext &context)

Need to add SCEBD term.

Would it be better to put this in its own DoF loop and do the if check once?

Member GRINS::ReactingLowMachNavierStokesAbstract::_p0_var

When we mandate C++11, switch this to a SharedPtr.

Member GRINS::ReactingLowMachNavierStokesBase< Mixture >::ReactingLowMachNavierStokesBase (const PhysicsName &physics_name, const GetPot &input, libMesh::UniquePtr< Mixture > &gas_mix)

Use std::move when we mandate C++11

Member GRINS::ReactingLowMachNavierStokesStabilizationBase< Mixture, Evaluator >::compute_res_steady (AssemblyContext &context, unsigned int qp, libMesh::Real &RP_s, libMesh::RealGradient &RM_s, libMesh::Real &RE_s, std::vector< libMesh::Real > &Rs_s)

Still missing derivative of species diffusion coefficient. rho*grad_D[s]*grad_ws[s]

Member GRINS::Simulation::check_for_adjoint_solve (const GetPot &input) const

This option name WILL change at some point.

Member GRINS::SolverParsing::solver_type (const GetPot &input)

We should just pass this object in from the calling function

Member GRINS::SourceTermBase::parse_var_info (const GetPot &input)

In the future, after refactoring Variable parsing, we should be able get the FE type and order information from there.

Member GRINS::StabilizationHelper::compute_G (libMesh::FEBase *fe, AssemblyContext &c, unsigned int qp) const

Should we inline this?

Member GRINS::StabilizationHelper::compute_g (libMesh::FEBase *fe, AssemblyContext &c, unsigned int qp) const

Should we inline this?

Member GRINS::SteadyMeshAdaptiveSolver::solve (SolverContext &context)

This output cannot be toggled in the input file, but it should be able to be.

Member GRINS::TurbulenceModelsBase< Viscosity >::_dim

Do we really need to cache this?

Member GRINS::TurbulenceModelsBase< Viscosity >::_rho

Create objects to allow for function specification

Member GRINS::u_var_name_default

Should we put the default physics variable names in a class instead of just GRINS namespace?

Member GRINS::Vorticity::element_qoi (AssemblyContext &context, const unsigned int qoi_index)

Need to generalize this to the multiple QoI case

Member GRINS::Vorticity::element_qoi_derivative (AssemblyContext &context, const unsigned int qoi_index)

Need to generalize this to the multiple QoI case