Problems with "on error"

[ArneBochmann]

I'm not realy familiar with Matcad but have some programming experiences.

For a Mathcad (MC13) user I have to program the fitting of a large number of spectra. There will be spectra with no real solution (non convergence) always - so I have to handle the error. Mathcad give the phrase "on error". I tried to include it in my programm but it gives some strange results. There will be the calculation of a vector hvec - without "on error" it ist a vector, with "on error" it is a scalar if there is not this "hvec <- guess" initial step on top of the program part.

I get normal results if I not include "on rrror" -> see "MC11 fano fit_SG without on error.mcd" (MC11) and "without on error.jpg"

Using "on error" hvec ist always the value off the initial step "hvec <- guess" if the4 calculation is ok, if there is an error hvec is that what I wrote left of "on error" -> see "MC11 fano fit_SG with on error.mcd" and "without on error.jpg".

What do I wrong?

Can someone help me?

Thanks

Arne

[RichardJ]

If you post a worksheet that relies on data files to work correctly please post some data files. I am >99% sure I know what's wrong but I want to be sure it works correctly after I fix it. If the Raman spectra are in some sort of sequence please post a part of the sequence that includes a spectrum for which the fit fails. I may be able to fix that too.

[jeanGiraud]

How do you get some result in Mathcad 11 ?

It does not have the n x n matrix "trace(M)" function.

No data set + "Illegal context"

jmG

[RichardJ]

It does not have the n x n matrix "trace(M)" function.

Just delete that line. It will not affect the program output.

[jeanGiraud]

Richard Jackson wrote:

It does not have the n x n matrix "trace(M)" function.

Just delete that line. It will not affect the program output.

Yes, but still get inc "illegal context"

Thanks, will read you tonight.

[jeanGiraud]

I don't understand:

If you have a spectrum, why don't you first get easily the generating function ? Once in hand the function, if you need some king of fitting for this function to be further processed, then the matter is a fitting session [whichever best fit method can be found, SVG, Cheby ...]. In other words: have the data set and you will probably get the function from collabs. Is that what you want , i.e: the function that generates the spectrum [or part of it] ? There are all sorts of Fourier filters that may apply to take care of noise as it might appear back in the generating function.

jmG

[ArneBochmann]

Dear Richard and Jean!

Thanks for your interest!

There is the complete dataset of the raman spectra the MCAD files I had send were wrote for (~10000 RAMAN spectra, but it could be more).

The fitting works well without "on error" (despite the convergence problems) but with "on error" not so I wasn't thinking about that it relies to the datas.

Some news: the version without "on error" works for this data set now - I saved it in MCAD11 and reopen again (MCAD13) - there were now convergence problems anymore but long caculation times for some spectra. Could be related to the MCAD11 save or that I use the debugging now - that behavior I have seen in other systems.

But I would like to work with "on error" because there will be arbitary datasets with wrong spectra for sure because there is not everywere silicon what we looking for but dust or something else - wromg spectra means not to match noise but no real data to fit. The "on error" version doesn't work even with MCAD11 save!

The "trace(hvec)" function is a output function of the debuging option with one parameter - I used it to see the intermidate results and the progress of the program.

This inc "illegal context" I haven't get - it works fine (MCAD13)?!

Would be nice if you could help me!

Thanks and Tschüß

Arne

[jeanGiraud]

Are you kidding ? sending 10000 columns of data for ONE (1) problem.

Just send ONE column of data, i.e : ONE spectrum. You may have a

problem of interpreting your own project: a spectrum is in the Fourier

domain, You should start working with raw data, that are just data

and just data aren't any spectrum. I'm not saying that your "black box"

does not output a spectrum, but it does not directly.

What type of data are they *.dat, *.txt, *.prn ... ?

If you have a Mathcad work sheet 32.4 MB, I'm not going to open

that kind of monster

..................................

"The compressed zip Folder is invalid or corrupted" <

That's where it stands .

jmG

[RichardJ]

jean Giraud wrote:

a spectrum is in the Fourier

domain,

That depends on what you consider to be the starting domain.

You should start working with raw data,

That is the raw data.

I'm not saying that your "black box"

does not output a spectrum, but it does not directly

The "black box" is a Raman spectrometer, and yes it does.

[jeanGiraud]

>The "black box" is a Raman spectrometer, and yes it does.<

_________________________

I understand that Richard, though in my times the gaz anlyzers [mass spectrometers] weren't so advanced . The Raman spectrometer is like the hand held thermometer, the probe inserted in the media reads mV, and displays °C .

[RichardJ]

Arne Bochmann wrote:

The fitting works well without "on error" (despite the convergence problems) but with "on error" not so I wasn't thinking about that it relies to the datas.

The fitting is not likely to throw an error even for very bad spectra. It may take a very long time to converge, and the parameters will be garbage, but it will converge to something.

Some news: the version without "on error" works for this data set now - I saved it in MCAD11 and reopen again (MCAD13) - there were now convergence problems anymore but long caculation times for some spectra. Could be related to the MCAD11 save or that I use the debugging now - that behavior I have seen in other systems

The file version used to save will have no effect on the convergence times. The trace window might, but it's not much (I timed it to be sure of that). Some of your spectra do have very long calculation times, but it's only a couple of them. They look very strange: the signal level is not much different to adjacent pixels, but the noise is much higher and the baselines are screwed up. I don't know what would cause that (Raman is something I do have a lot of experience with). Some of the spectra have bad cosmic ray spikes too, but they do not seem to affect the convergence time. They actually don't seem to affect the fit that much either, but it would be better if you removed them. The fitting can be greatly sped up by switching from genfit to minerr: see the attached worksheet.

But I would like to work with "on error" because there will be arbitary datasets with wrong spectra for sure because there is not everywere silicon what we looking for but dust or something else - wromg spectra means not to match noise but no real data to fit.

As I mentioned above, that will usually not cause it to fail to converge though. It will just give you garbage results. It will also give you very large RMS residuals, so you can easily identify those spectra after the fit. Then you could replace them with the average of the nearest neighbors.

The "on error" version doesn't work even with MCAD11 save!

The file version will make no difference to what works after the file is reloaded, except to the extent that certain things that are not supported in earlier versions will have been removed during the save. The things that are removed are only those things that cannot be saved in the older format, not things that simply did not work in earlier versions. An example would be the secondary axis on 2D graphs.

This inc "illegal context" I haven't get - it works fine (MCAD13)?!

That's because you used range variables in the loop defintions in the program. That's not supported in version 11.

[ArneBochmann]

Dear Richard!

Great thanks for helping - I have seen my problem in on error now! Thanks for the new program too! I will delete my old stuff and rearrange a little bit - so my colleague can work with.

With the cosmic spikes and high noise or wrong data - as long as this is happen to minorr number of points only this ist no problem.

The data are from 2D Raman scans of thin layer multicrystalline silicon cells with small crystalls, high internal stress (variation), probably no homogeneous doping and some inclusions or holes in the layer.

Thanks again and Tschüß Arne

[jeanGiraud]

>That's because you used range variables in the loop definitions in the program. That's not supported in version 11.<

________________________

Mathcad 11 does support the range variable in the loop definition. It supports as a scalar variable, thus preserving the scalar properties of the function as is or as treated in the loop.

jmG

[RichardJ]

jean Giraud wrote:

Mathcad 11 does support the range variable in the loop definition

Since you saw the error message for yourself, it obviously does not support it and I can't see why you would try to claim it does.

This works in MC12, MC13, MC14, and MC15. It does not work in MC11.

It supports as a scalar variable,

If it's a scalar variable then it's clearly not a range variable!

[jeanGiraud]

Read more: read the work sheet posted yesterday "IsScalar"

More detailed and tutored. It made Mike happy, at least it

clarifies once for all and for ever.

[RichardJ]

Read my reply there. A range variable (or a range value) is not a scalar.

[jeanGiraud]

Your interpretation in term of Mathcad is wrong. No matter your arguments, my point was to clarify what Mathcad considers as a scalar variable in terms of the numerical maths the user applies, that Mathcad checks first internally IsScalar, and if not This is not a scalar. The numerical integrator does not care whether scalar or discrete because it starts calculations on the limits and continues on that. For the derivative, the process is much different and needs the range variable scalar in term of Mathcad and in term of the numerical algorithm, not in terms of what you would like it to be. There are more than the derivative, but this example is sufficient to guide the user of what he may be doing incorrect, especially when too far deep incorrect Illegal context .