What you say may well be true, but since the Excel imports the Mathematica code as ascii, that is all I wanted and it served the purpose of identifying a code error. That same code when recopied from Excel into Mathematica gives the same results as before the export. The issue remains, where did that error come from originally? Since for me it appears to be a one-off issue, I can just be cautious about accepting anything at face value.

With regard to the imaginary component, it should come from some precision or accuracy limits, though setting the AccuracyGoal does not improve things. The NIntegrate process simply reduces the size of the imaginary component as I proceed with the parametric analysis until is quickly disappears. Unfortunately, it is large where I need it to be negligible. That is what I am working on now.

Regards,

Luther 

Not sure which comments I am replying to, but thanks for the suggestions. My use of Excel was simply to copy the code that was giving me problems into a separate applications. Sure enough, there was one term that I determined was the culprit. I was doing a parametric model and the results of the second parameter iteration looked out of scale, so I went back to the first iteration and simply copied and pasted the Mathematica code into Excel and the culpit showed up. I also played around with changing the order of integration with no changes.

The imaginary component of the solution is larger than the real part! Since the models are simply volumes and since the integrand does not have any poles, the size of the imaginary component surprised me.

I wanted to plot the integrand, but it is a six-variable function and I simply cannot figure out how to plot it to look for pathological conditions. As for plotting the solution set, I have yet to figure out how to perform a "batch" parametric variation within Mathematica and then collect and plot the results using Mathematica. At this point, I am doing it the hard way and plotting the results in Excel.

I am just getting into learning how to tell NIntegrate what method or strategy to use in performing the integration. The note that often comes up about a pole or oscillations does not seem to hold, though the way NIntegrate samples may be part of the problem.

The "bug" seems to be that the value 11.4 in Mathematica looks like ||.4 in Excel...pretty obvious. It only occurred in one of the instances of the value 11.4 that appeared in the integrand...the others were ok, so I am hard pressed to understand what the underlying bit structure is that was corrupted that turned 11.4 into ||.4.

That's all for now, but if and when I make any headway, I will report back.

Luther

I frequently run small test calculations in which I do the same problem symbolically and numerically and compare the results.
Another possibility for numerical calculations too large to do symbolically is to run the problem using different methods.  I believe NIntegrate
has a number of methods.   Also, it is not unusual for the numerical methods to return a result with a very small imaginary part, which I ignore
if I know the result has to be real rather than complex.  Finally, sometimes Mathematica results contain a symbol which doesn't appear in OutputForm,
which may explain why you saw something different in Excel.  I think that's probably a bug.

I was in the business, so I know that is true. That was not my question.

The question is, "In the presence of the possibility of such errors, what procedures would Mathematica recommend to catch the existence of such errors?"

My take is that no matter what mathematics we put into a model, we must re-do it in another order and see if the answer is the same.

On another note, what does it mean if a parametric model, in my case an NIntegrate function, throws off a complex value for certain parameters that, as they become larger, transitions to a purely real value? 

Thanks for you answer.

Luther