Hi, During our intermittent discussions about the partial separability work, both before the submission and during the AMR proposal writing we floated the idea of eliminating a loop that was considered wasteful by you, but convenient from an implementation standpoint by me. Specifically: The statements: #pragma $adic_partiallyseparable, fquad, flin *f = area*(p5*fquad+flin); were converted originally to: #pragma $adic_partiallyseparable, fquad, flin ADIC_SPARSE_Create1DimArray(&__adic_temp_f, ad_var_max); for (__adic_temp0 = 0; __adic_temp0 < ad_var_max; __adic_temp0++) { __adic_temp_f[__adic_temp0] = (area * ((p5 * fquad[__adic_temp0]) + flin[__adic_temp0])); } ADIC_SPARSE_Summation(f,__adic_temp_f,ad_var_max); where the grad_array of f is dense and large in size. f is an object of the class SparseDerivSeparable. The grad_array of __adic_temp_f, fquad, and flin are of size p, where p is the number of colors used by ColPack to compress the sparse elemental Jacobian. These variables are objects of the class SparseDeriv. DERIV_TYPE is typedeffed to SparseDeriv SparseDerivSeparable is a child of SparseDeriv.SparseDeriv contains a static array: double grad[ADIC_GRADVEC_LENGTH]; and SparseDerivSeparable contains a dynamically allocated array: double *grad;. The only location where a SparseDeriv object is used to compute a SparseDerivSeparable object is in the ADIC_SPARSE_Summation function. In the sparsity detection mode ADIC_SPARSE_Summation registers the sparsity patterns of __adic_temp_f. In the computation mode, uses the registered patterns along with the ColPack routines to compute f from __adic_temp_f. I went ahead an implemented a version that did not require a loop that calculates each element of __adic_temp_f. The output is given below: #pragma $adic_partiallyseparable, fquad, flin DERIV_TYPE *__adic_temp_flin; DERIV_TYPE *__adic_temp_fquad; ad_var_26 = ADIC_SPARSE_max(ad_var_0,ad_var_1); ADIC_SPARSE_Summation(__adic_temp_fquad,ad_fquad,ad_var_26); ad_var_27 = ADIC_SPARSE_max(ad_var_0,ad_var_1); ADIC_SPARSE_Summation(__adic_temp_flin,ad_flin,ad_var_27); ad_TempVartmp_7 = DERIV_val(ad_p5) * DERIV_val( *__adic_temp_fquad) + DERIV_val( *__adic_temp_flin); ad_TempVarSymbol_12 = DERIV_val(ad_area) * ad_TempVartmp_7; ad_TempVarlin_30 = ad_TempVartmp_7; ad_TempVarlin_32 = DERIV_val( *__adic_temp_fquad); ad_TempVarlin_33 = DERIV_val(ad_p5); ad_TempVarlin_31 = DERIV_val(ad_area); ADIC_SetValue( *f,ad_TempVarSymbol_12); ADIC_SetDeriv (DERIV_TYPE_ref(ad_area),DERIV_TYPE_ref(ad_TempVarprop_55)); ADIC_SetDeriv(DERIV_TYPE_ref(ad_p5),DERIV_TYPE_ref(ad_TempVarprop_56)); ADIC_SetDeriv (DERIV_TYPE_ref( *__adic_temp_fquad),DERIV_TYPE_ref(ad_TempVarprop_57)); ADIC_SetDeriv (DERIV_TYPE_ref( *__adic_temp_flin),DERIV_TYPE_ref(ad_TempVarprop_58)); ADIC_Sax_3 (1 ,DERIV_TYPE_ref (ad_TempVarprop_58 ),ad_TempVarlin_32 ,DERIV_TYPE_ref (ad_TempVarprop_56 ),ad_TempVarlin_33 ,DERIV_TYPE_ref(ad_TempVarprop_57),DERIV_TYPE_ref(ad_TempVarprop_59)); ADIC_Sax_2 (ad_TempVarlin_30 ,DERIV_TYPE_ref (ad_TempVarprop_55 ),ad_TempVarlin_31 ,DERIV_TYPE_ref(ad_TempVarprop_59),DERIV_TYPE_ref( *f)); } Right now, all temporary variables are objects of SparseDeriv. There are two calls to ADIC_SPARSE_Summation that assign values to the temporary variables __adic_temp_flin and __adic_temp_fquad These variables will be defined as SparseDerivSeparable within ADIC_SPARSE_Summation. Here begins the problem, the XAIFBooster output for the statement area*(p5*fquad+flin); requires ADIC_Sax_# and SetDeriv calls which causes assignments of SparseDeriv to SparseDerivSeparable and vice-versa. Statements such as: ADIC_SetDeriv (DERIV_TYPE_ref( *__adic_temp_fquad),DERIV_TYPE_ref(ad_TempVarprop_57)); can probably be handled by intelligent declaration of temporaries. However, the statement ADIC_Sax_3 (1 ,DERIV_TYPE_ref (ad_TempVarprop_58 ),ad_TempVarlin_32 ,DERIV_TYPE_ref (ad_TempVarprop_56 ),ad_TempVarlin_33 ,DERIV_TYPE_ref(ad_TempVarprop_57),DERIV_TYPE_ref(ad_TempVarprop_59)); is trickier to handle as it requires us to define the computation between a SparseDeriv type and a SparseDerivSeparable type. ad_TempVarprop_56 is just a temporary holding the grad_arrary of ad_area which is a SparseDeriv object. What can be noted is that ad_area is a non_elemental value that is also in effect inactive. So if we integrate ActivityAnalysis, we should be able to keep ad_area inactive (double type) and so the above situation should not occur. Are there any thoughts on this? I have not yet talked about possibly using f later on in the code in this email. I am assuming that the succeeding code is all SparseDerivSeparable. We will have to work out how to have different types and variables declaration co-existing harmoniously. Thanks, Krishna