Create PD_BACKGROUND

[rowlesmr]

Well, it is now in the future...

Can record: polynomial background, chebyshev, straight line segments.

More to come!

[rowlesmr]

The layout has failed, I think, due to the capitalised "Chebyshev" in the data names. Also, because I've put in "UNKNOWN" for the unit codes for some data items. In the current implementation, the X-coordinate of the background function is whatever it is in the calculated pattern; I haven't figured out how to set that yet, so the units for some things can't be known.

I don't understand why the ddlm has failed; afaik I've added the correct data items and links. But it is also midnight and I start work tomorrow, so...

[rowlesmr]

Other ideas: diffuse bkg, a per-phase way of listing bkg values point-wise so that you can add them up, or scale them.

[jamesrhester]

Ok, so I don't understand why the Chebyshev coefficients have to be put in a list as well as the orders. Either we can simply define a list, and then the position in the list (starting from 0) is the order of the Chebyshev polynomial, or we can have order as a number and then tabulate in a loop. I think the list idea is probably the most efficient.

[rowlesmr]

Ok, so I don't understand why the Chebyshev coefficients have to be put in a list as well as the orders.

It was late.

the position in the list (starting from 0)

This is The Way

[rowlesmr]

Is it possible to have a Matrix of two values, one of which is a Number and the other a Measurand?

[rowlesmr]

Yes! Now, reminder to self to not commit after bedtime.

[jamesrhester]

Is it possible to have a Matrix of two values, one of which is a Number and the other a Measurand?

Essentially no. Arbitrarily nested lists with heterogeneous types were a part of the original DDLm vision, but the thinking has evolved since then along the lines of

1. Writing code that can handle such complex data structures is time-consuming
2. Differing types implies each value is used in a different way, which in turn implies that they have a distinct meaning, so are better presented as separate quantities

The original DDLm dictionaries created synthetic single-data-name keys that were the values of multi-data-name keys collected into a list. Of course, the first thing that was done when calculating with these keys was to split them up again, so they were just a convenient packaging mechanism for dREL and hid the meanings of the individual data names that they were formed from. Another use was to return eigenvalues and eigenvectors together after calculations rather than obtain them separately.

[rowlesmr]

@briantoby : I would like to add more GSAS-type backgrounds. Is there a canonical listing of the functions you use? I've got a copy of the original GSAS manual, and am finding it difficult to extract the mathematical functions behind the code in GSASII.

Also, in GSAS, can you have more than one type of background function active at a time?

[rowlesmr]

Any ideas on how to indicate on which X-axis the bkg values are calculated?

[rowlesmr]

I think that's all the ones commonly used in topas and listed in the gsas manual.

Do any others come to mind? Any ideas on better naming?

[rowlesmr]

Any ideas on how to indicate on which X-axis the bkg values are calculated?

This also touches on https://github.com/COMCIFS/Powder_Dictionary/pull/89#issuecomment-1397826731

the way in which a value is used (should not be) changed by the values of other data names

There are many cooordinates against which a background can be calculated. I think the Y-coordinate can be assumed to be intensity. The X-coordinate, if limited to _pd_meas-type units can be 2Th, TOF, position, or detector_id/channel*. If you then also allow derived units, you're going into energy, wavelength, q, and d.

That is a lot to duplicate in each type of background function.

I've commited one solution, which is to directly break @jamesrhester 's rule above: a data item for a diffractogram which sets they type of X-coordinate used for all background functions.

* I still need to do a worked example on how an EDXRD pattern would work with detector_id representing channels.

[jamesrhester]

I'm generally happy with the way this PR looks and it seems easy to me to see how it would be used to describe background functions. I can't see another way to describe the abscissa given that you are not guaranteed to have only one type of abscissa present in PD_CALC. I'm not too worried about this violation of the "don't change the meaning" rule as the alternative is a large number of data names that are essentially the same.