Since 'w' is used as a loop index and hence always a numeric value, it doesn't make much sense (to me) to integrate 'L1' with respect to 'w' -

As provided the quantity 'L1' contains the unknowns a1, a2, b2, c1, c2, c3, f1, k1, k2, k3. Im guessing that these are meant to be a1[w], a2[w], b2[w], c1[w], c2[w], c3[w], f1[w], k1[w], k2[w], k3[w]}

If I make these changes, then 'L1' evaluates to a (complex) numerical constant, in fact

-0.00009976269238 + 0.04386238846*I

for loop index values d=-w and w=0.

See also my comments in the attached worksheet

Download cmplInt.mw

@dnaviaux 

a simple formatted prin statement ( ie printf() ), as in the attached

  example_results:=<1,2,3,4>:
  example_names:=<"resistor","opamp","name3","name4">:
  printf("\n\n\t\t    Quantity\t    Value\n\n");
  seq( printf( "\t\t%12s:\t%12.8f\n",
               example_names[j],
               example_results[j]
             ),
       j=1..numelems(example_names)
     );

   whihc will produce

            Quantity        Value

              resistor:      1.00000000:
               opamp:      2.00000000:
               name3:      3.00000000:
               name4:      4.00000000:

That an alternative is to upload your worksheet here, using the big green up-arrow in the Mapleprimes toolbar and (probably?!) someone here will find/fix the error for you

The dsolve() command is returning a complex number (ie of the form a+I*b)

Maple will handle complex-valued IVP problems but not complex-valued BVP problems - see the extract from the Maple help below (emphasis added)

All IVP methods can be used for complex-valued IVPs with a real-valued independent variable (though for the default stiff and nonstiff IVP methods, it may be necessary to specify that the problem is complex via the complex option). None of the BVP or DAE methods can currently be used for complex-valued problems, requiring the system be converted to a real system before calling dsolve.

Converting your complex-valued system to a real system is not too difficult(?), but can be time-consuming,  so before doing this it makes sense to ask a very simple question.

For your specific problem, does it make sense for any of the dependent variables ( ie f(eta), theta(eta), chi(eta) ) to have complex values?

If you are expecting only real values for your dependent variables, the fact that Maple is producing complex values is (often) a sign that there is  "typo" somewhere in the definition of the system.

This is a problem I have always had "occasionally", but over the last couple of days, I haven't been able to display any worksheet.

Not convinced that it is user OS/browser issue - my default is Win7+FireFox

@mmcdara 

See my earlier answer.

We seem to have the same Maple build ID. The only "difference" seems to be that I am running 64-bit Windows 7, while you are using MacOS

It is rare that use of the 'range=' option is "beneficial" - so unless you have a very good reason for using it, then don't

1. Using this option means that Maple not only generates a suitable procedure to compute the solution it actually uses this procedure to compute/store the solution for the whole of the specified range. It will store the solution at all values of the independent variable(s) used in the calculation. The values of the independent variables will be determined by the "error control" for the solution method. This can result in the storage of a lot of data - most of which you will (probably) never want/need
2. If this option is omitted then Maple will just generate a procedure which can be used to compute the solution - the solution is not computed/stored at this stage.. Subsequent use of this procedure will actually cause the solution to be computed - and it is rare that such subsequent use will ever require the complete solution to be stored. For example
   1. If you just want the value of dependent variables at (a) specific value(s) of the independent variable(s), then one only needs to store values for the number of preceding points which are necessary to compute the next point. This number will be dependent on the method being used, but (in general) it will be <10 - so one should never run into a storage limit. The solution procedure 'knows' how many previous points are needed to compute the next one - and won't store any more than this.
   2. If you wish to produce plots using odeplot(), then the number of values which have to be stored is essentially under the control of the plot routine - in other words sufficient to produce a nice smooth plot, but (in general) this will far fewer than the number of points required for error control in the ode solving procedure.

@manju 

It is trivial to generate random values for your parameters, plot the required surface and annotate the plot with the parameter values.

My problem is that I do not understand your requirement

"constants should randomly take the best values."

I understand the requirement

"constants should take random values."

and the requirement

"constants should take the best values."

provided that you supply some criteria for deciding what is "best"

But constants cannot be both "random" and "best"

@manju 

You say

I want that all the constants should randomly take the best values.

Define 'best' !

@s265344 

SolveEquations() is definitely a command in the DirectSearch package - see my original worksheet, and the attached. I can only assume that you have an installation problem. What happens when you type DirectSearch in the Maple help???

In the attached, increasing the value of 'c' to 1000 - all residuals are quite small, values of all variables are still quite small

Download DS2.mw

@mmcdara 

Maybe one of the options in the attached covers your requirement?

Download globLoc2.mw

@vv

Your final execution group produces a 1X2 array of plots.

For reasons which escape me, no plot arrays never render correctly on this site

With the latest Physics Version (884), I find that the setting of warnlevel() makes no difference!????

Only obvious difference between nm's installation and mine, is that I'm (still) running Windows7, although I can't believe the underlying OS should make any difference

Download warnDiff.mw

@Jaqr 

that you use the big green up-arrow in the Mapleprimes toolbar to upload the actual worksheet demostrating the problem. rather than have us guess what it content might be.

@acer 

It has always bothered me that the help page for seq() states (emphasis added)

Note: The index variable i is NOT private to the seq invocation.  It is recommended that you always explicitly declare the index variable to be local inside procedures.

This begs the obvious questions:

1. Why only "inside procedures", what about "top-level"?
2. Why is it  "recommended" rather than "mandatory"

Observe that the the help page for the (more-or-less-related) commands add() and mul() states

Note also that any previously existing value assigned to the index variable i is restored after the add or mul invocation. Thus the value of any local or global variable of the same name visible at the time the add or mul is executed will not be affected.