nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

How to extract p-values and factors from graphical report to simple table

mclayton200

How to create simple list of parameter names and p-values for Dunnett Test Comparison of many product parameters, forsot to Split Plot Lot data vs Control Lot in DOE analysis.

In semiconductor industry we run hundreds of experiments per factory per year, and there are hundreds of test parameters at end of line that must be tested for shifts from the "process of record" or "control" split for each of the other experimental factors. Goal is often simply best yield, but since raw parametric values for each test may impact customer field behavior, we must sort by p-value to begin further studies of those parameters which have shifted using this simple comparison of means test. JMP gives us graphical report, with p-values in small tables under the comparison plots, hundreds of them. How do we extract those p-values along with factor names and product parameter name for ranking purposes. Suggestion has been to use excel V-lookup. Any better ideas within JMP?

Accepted answers

laural_

The simple answer is to right click on one of those small tables and select "Make Combined Data Table". If you table is a Parameter Estimates, it puts all those parameter estimates tables together and will add extra columns representing the X and Y factors associated with each table. JMP will also add extra columns for by variables.

This works on all the tables in one JMP report window.

The harder answer is the scripting answer.

All comments

laural_

This works on all the tables in one JMP report window.

The harder answer is the scripting answer.

Jeff_Perkinson

Have you looked at the Response Screening platform in JMP 11?

It's made especially for testing hundreds or even thousands of responses. It incorporates a false-discovery rate approach to ensure correct declarations of significance. Simply saving all the p-values from Fit Y by X won't do that.

You can also turn it around to examine only the effects with practical significance, that is, effects where the difference makes a practical difference.

Here's a nice video showing off the Response Screening platform.

https://www.youtube.com/watch?v=IoMYIGPuDKk

-Jeff

mclayton200

Thanks. Have never used that response screening tool for this use, adn the overview explains why it makes sense.

So I am re-testing our data using those tools now...but have not gotten answers back yet from design engineers on PRACTICAL SiGNIFICANCE (I tend to use Cpk tests and if marginal, I use simple p-values....but if Cpk is very high, may ignore large shifts and not imporant. That designer input is coming....so can add that input as well.

The FALSE DISCOVERY RATE and the FDR plot are new to me.

I grew up on JMP 4 thru 8 mostly, now have 11. And I am engineer, not statistician. We also graph the data and share it with design and test engineers for starters...but management always asked for sorted p value tables as well for QA purposes in case design and test engineer miss important shifts TO THE CUSTOMER that was not known when datasheets were released and products were qualified. So we keep the raw data until 7th year of new product release, ten archive it in QA.

Lately clients include design centers that use foundries to make chips, and have little input on process details such as PM times, tool to tool matching issues, etc...except that they see variability in yield per lot. That triggers screening DOE's using "likely suspects" based on fail bin codes and parametric shifts, and foundries help run the experiments and share in the results..without simply dumping all their factory data into our DB for all products. Normally the Y by X plots and Dunnett tests show clearly the stongest signals and then replicates confirm the solution. But since DOE has to be replicated one batch at a time for the final process change qualifications, this new FDR approach may become useful as we learn to use it.

Thanks, the two of you showed us fast way to give mgmt what it requested, and possibly more robust solution long term.

By the way, datasheet spec limits can be wrong for new applications which get surprised when key parameters shift by several sigma within an 8 sigma tolerance window. So documenting raw data shifts graphically is important. And those case studies are archived with each set of product test specs and process flow specs for many years.

(Ford Motor taught us that years ago at Motorola.) GM is just catching up on those kinds of "small details."

charliem

You can do it in script also in straightforward way.

Here is how I do it:

// This first block here makes a report based on the the oneway chart (called here obj)

// Then it extracts table box # 4 which it then makes into a data table.

obj_r= obj << report;

tb= obj_r[Table Box(4)];

tb2 = tb << Make Into Data Table;

// Once it's a data table, you can extract the specific p-values you want, or

// just get them all. What I've done below just gets them all:

Column(3) << Set Name("pv"); // I'm changing the name of the column (see note below)

pcol = Column(3); // the column that has the p values

gcol = Column(1); // the column that has the "Levels", which I'm calling the group

pval = pcol << GetAsMatrix; // vector of p-values (one for each group)

gval = gcol << GetAsMatrix; // vector of groups (one for each group)

Note: regarding the name change of the p-value column to pv, I did that jsut to get the hyphen out of there because the hyphen can get in the way. For example if I go looking for a specific p-value by looping on the rows of the table, JMP seems to not like this construction: ":p-value" so I just changed the name to pval so I can just access ":pv which it performs without incident.