Questions

1. Why name it Phalanx?

The phalanx was one of the most dominant military formations of the Greek armies in the classical period. It was a strictly ordered formation. The Phalanx software library figures out ordered dependencies of field evaluators. A second more obscure reference relates to the US Navy. The Phalanx software package was designed to provide nonlinear functionality for the Intrepid itegration library. Intrepid was the name of an aircraft carrier during in WW II. Modern US aircraft carriers are protected by a Close-In Weapons System (CIWS) named the Phalanx. Finally, the PI of this project is an avid strategy warfare gamer and leans towards military references.

2. Why does the evaluation type exist?

This allows for multiple evaluations that used the same Scalar type, but different evaluators specific to the CalculationType. For example, evaluating the Jacobian (derivative of the residual with respect to the degrees of freedom) and the parameter sensitivities (derivative of the residual with respect to the parameters) both use the same Sacado data type. They both want derivatives but with respect to a different set of entities.

3. Why do evaluation types have arbitrary data types. Shouldn't all fields of an evaluation type require the same scalar type?

In 99% of the use cases, the answer is yes! By changing the scalar type for a specific type of computation, you can break the dependency chain and get incorrect answers. For example, if computing a Jacobian, you would use a FAD scalar type instead of a double scalar type for the evaluation. By mixing FAD and double fields in an evaluation type, you will lose derivative components and get incorrect sensitivities. But there are some use cases where one might want to use different data types. If the user knows that certain evaluation routines have no derivative components, they can bypass the AD chain by switching to doubles for that part of the computation. The is an expert only user mode, but we allow for it.

4. Why are the evaluators templated on the evaluation type?

Each evaluator must be templated on the evaluation type to be able to (1) allow for the expert use mode described in FAQ

Why do evaluation types have arbitrary data types. Shouldn't all fields of an evaluation type require the same scalar type?

; (2) use the automated factory class (PHX::EvaluatorFactory) to build the evaluator for each evalution type.

5. Why is the MDALayout object not templated on the ArrayOrder type?

This introduces many complications in the comparison operator (operator==) during a comparison of a reverse and natural data layout with the same (but reversed index types). Should these objects be the same? Probably, but this might introduce some confusion. So in an effort to keep things as clean as possible, there is no differentiation based on forward or reverse (Fortran) array ordering. If we were to introduce this, then we would have to add another method to the DataLayout base class to allow for checking the ordering. If mixing natural and reverse ordering becomes common, we may revisit this decision.

6. My code seems to be running slow. How can I speed it up?

See the section on Performance in the Users Guide that gives recomendations on how to maximize the efficiency of your code.

7. Compilation take a long time when minor changes are made to an evaluator. How can I speed this up?

Explicit template instantiation can be used to speed up evaluator development builds. See the section on Performance in the Users Guide.

8. Valgrind gives a memory leak error in all evaluators when using the PHX::ContiguousAllocator with Sacado::DFad based fields. What is the problem?

The contiguous allocator is allocating space for all variables in an evaluation type in a single contiguous chunk of memory. We allow for multiple scalar types in an evaluation type so the array is allocated using the type char and then based on scalar type sizes (using sizeof method) along with proper alignment, pointers to blocks of memory are handed to the fields using a reinterpret_cast. DFad uses new to allocate the derivative arrays, so this memory is not contiguous. The problem is that the field array memory is deleted as a char instead of it's various data types, so all DFad derivative arrays are leaked during the destruction. There are two ways to alleviate this: (1) write a special Allocator to call the destructor of the field type for each field. (2) Have Sacado implement a version of DFad that allows the user to allocate the DFad array and pass in the pointer during construction. This will also require a new allocator. Choice (2) will be handed in Phalanx in a later release. Our current suggestion is that one should use DFad only if using the PHX::NewAllocator and use SFad if using the PHX::ContiguousAllocator.

9. The evaluators contain boilerplate. Is there an easy way to automate creating the evaluators?

YES! There is a python script that will automatically generate the skeleton for evaluators. It is found in the "scripts" directory of phalanx and is called "phalanx_create_evaluator.py". It will be install in the "bin" directory when trilinos is installed. Example use can be found at the end of section Step 5: Write your Evaluators of the Users Guide.