This repository has been archived by the owner on Nov 8, 2022. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 19
Weibull Distribution average calculations do not consider applied shift? #31
Comments
Hey Cory, I can confirm what you are seeing. This appears to be a bug. To outline what i'm seeing:
This bug is unfortunate. A suggested work around is to define the distribution as Weibull without the shift and then define an rtaResult as "2 + the cell containing the Weibull". This will produce the same results but will be more explicit. Even though it ignores the shift, the OAT analysis is still useful because it outlines the impact of the uncertain part of service time The width of the tornado bar and slant of the spider line are driven by the uncertain part of the service time and the shift is will only move them along the x and y axis respectively. Thanks for bringing the issue to our attention! |
Thanks for the timely response!!!
I wanted to make sure that I was using the SW correctly, as it was my first
day of use. After about two hours of my own research I convinced myself I
was right, and I'm glad those hours weren't wasted!
Have a good day.
…-Cory
On Thu, Nov 7, 2019 at 4:38 PM boz ***@***.***> wrote:
Hey Cory,
I can confirm what you are seeing. This appears to be a bug. To outline
what i'm seeing:
- The value being displayed in the cell does not include the shift. I
tested this for other distributions as well... it is not only a condition
of weibull.
- The simulated values in both RTA and Native Excel mode do consider
the shift and create appropriate distributions (this is why the analysis
wizard looks correct and op functions return expected results)
- The OAT analysis chooses the evaluation percentiles based on the
unshifted distribution.
This bug is unfortunate. A suggested work around is to define the
distribution as Weibull without the shift and then define an rtaResult 2 +
the cell containing the Weibull. This will produce the same results but
will be more explicit.
Even though it ignores the shift, the OAT analysis is still useful because
it outlines the impact of the uncertain part of service time The width of
the tornado bar and slant of the spider line are driven by the uncertain
part of the service time and will scale with the shift.... the shift is
will only move them along the x and y axis respectively.
Thanks for bringing the issue to our attention!
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#31?email_source=notifications&email_token=AA4LE7BN44CP7NBFDE62D4DQSSRF3A5CNFSM4JKOCB32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDOGVGI#issuecomment-551316121>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA4LE7HDYB3SCVBHL5OPFADQSSRF3ANCNFSM4JKOCB3Q>
.
|
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
I have a variable on a Weibull distribution modelling queue time for machines waiting to be loaded in a value driver calculation for mining equipment. I'm applying a shape of 2.1, scale of 1.018, and a shift of 2. Essentially, no machine load time is under 2 minutes.
The average output I'm getting in the cell is .90, which is mathematically correct if we only consider the average is created by the shape and scale. The average value displayed does not appear to consider the shift applied to the distribution.
Changing the cell values to display random sampled values has never yielded a value under 2.
When I view the output of the distribution being used, I am seeing that there are no values under the shifted value being sampled, which is expected behavior. See blue arrow on distribution view. However, OFAT output also carries the same error, and does not respect the shifted distribution.
I am using the 64 bit version, and have no ability to use a 32 bit due to enterprise restrictions. I'm including the sheet, cell E23 is the one in question.
Monte Carlo Driver Tree for Fleet Comparison.xlsx
The text was updated successfully, but these errors were encountered: