Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bug in Resolutions used for Fractional Factorial Design #8

Open
avanelc opened this issue May 27, 2024 · 6 comments
Open

Bug in Resolutions used for Fractional Factorial Design #8

avanelc opened this issue May 27, 2024 · 6 comments

Comments

@avanelc
Copy link

avanelc commented May 27, 2024

I encountered an issue with the add_design method in the doepandas package when specifying resolutions for fractional factorial designs with 6 factors. The method allows for the selection of a resolution that is not standard, resulting in an error.

Issue Details:
When attempting to create a design with resolution=VI for 6 factors, the method fails with a ValueError indicating "design not possible." But when setting resolution=V for 6 factors, the design given is with 32 runs. Although, resolution V does not typically exist for 6 factors in standard design tables.

Standard Resolutions:
For 6 factors, the standard resolutions are:
Resolution IV: 16 runs (1/4 fraction of the full factorial)
Resolution VI: 32 runs (1/2 fraction of the full factorial)

Expected Behavior:
The method should either generate a valid design for compatible resolutions or provide a descriptive error message indicating that the requested resolution is not valid for the given number of factors.

@relf
Copy link
Owner

relf commented May 28, 2024

Hi, could you provide a simple code to reproduce the issue? By the way, I did not find anything about a doepandas package on Pypi.

@avanelc
Copy link
Author

avanelc commented May 28, 2024

Hi, could you provide a simple code to reproduce the issue? By the way, I did not find anything about a doepandas package on Pypi.

Hello! Sorry I was looking at another method, I meant to write 'fracfact_by_res' method from pyDOE3

Sure! Let's consider an example from a manufacturing context with measurable factors. Here are six factors, each with two levels, expressed numerically and with units:

Factors and Levels:
Machine Speed: 100 RPM (Level 1), 200 RPM (Level 2)
Temperature: 150°C (Level 1), 200°C (Level 2)
Pressure: 10 Bar (Level 1), 20 Bar (Level 2)
Material Thickness: 1 mm (Level 1), 2 mm (Level 2)
Cooling Rate: 5°C/min (Level 1), 10°C/min (Level 2)
Feed Rate: 1 m/min (Level 1), 2 m/min (Level 2)

@relf
Copy link
Owner

relf commented Jun 12, 2024

I should have mentioned that I do not know the function fractfact_by_res() (and I do not know anything about the standard table you mentioned). For the record, I've forked pyDOE mainly out of my need for LHS and Fullfactorial DOEs.

From what you stated, I understand that fractfact_by_res(n=6, res=5) should raise ValueError instead of returning 32-points doe while fractfact_by_res(n=6, res=6) should return a 32-points doe instead of ValueError. Correct?

Feel free to contribute with a PR as I think I will have no time to dig into this.

@relf
Copy link
Owner

relf commented Jun 13, 2024

I am wondering if this issue could be fixed by this pending PR in pyDOE2.

@avanelc
Copy link
Author

avanelc commented Jun 21, 2024

I think that the reintegration of the bofire code on pyDoE3 (#11) would solve this issue.

@relf
Copy link
Owner

relf commented Jun 21, 2024

Did you test? Would you mind contributing with a PR?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants