ESPlannerPlus Running The Wrong Profile
I have encountered an unusual problem in ESPlannerPlus a couple of times. It is very subtle and has happened only only twice in hundreds of usage sessions since upgrading from the 2.19.82 to 2.20.38 versions. I cannot yet reproduce the problem at will so thought I would at least inquire to see if anyone else has run into this before.
Problem: ESPP runs a previous profile regardless of which profile is selected for simulation.
The general scenario where I have seen this is after creating a Profile using Save_As, modifying it as desired, and then creating a report. The result is that the original profile is run again rather than the new one.
Longer Example: (Doesn't always show the problem so no use in submitting a ticket just yet.)
1) Take a Profile called BASE
2) Run a report.
3) Save_As a new profile called CASE_1
4) Modify the parameters you are evaluating in profile CASE_1
5) Create a report for CASE_1
At this point, ESPP runs but instead of running the profile CASE_1, it reruns the profile BASE.
After it does it once, running ANY other profile in your collection ALWAYS results in just re-running profile BASE. The only way I found to fix the problem is to close and then reopen ESPP. Once again any profile can be used and everything works normally.
Has anyone else seen such behavior? If I can reliably find a way to reproduce it, I will submit a support ticket but wanted to see if this has ever been seen before.
John
RSS
It's not impossible for ESPlanner to get "lost" about which profile you intended to run. It should be very, very rare. It's also easy to mix things up because the profile names can be the same.
When the Report option page opens, look at the name of the profile listed on the banner. That's the one that will get run.
You can insure you get the profile you intended by clicking the profile name. No need to close and reopen.
Thanks, Lowell,
This is indeed a very, very rare event. I have been using ESPP extremely heavily in the past few weeks and have only seen this twice. Next time it happens, I'll be sure to click on the actual profile entry and then note the name selected in the banner. (I cannot recall if I have tried clicking on the profile name or just one of the entry folders.)
John
I've seen this from time to time. Hard to say a % of times I've seen this, but should be less than 2%.
Whenever it happens, I either just re-select the profile I want or restart ESPlanner.
Best,
Brian
Lowell,
I was able to reproduce the problem again this morning. This time, I noted the profile name in the banner.
The banner was showing the correct profile name to be run BUT as soon as I pressed the "Create Report" button, the banner changed to "Wait...", then changed to the wrong profile name and began running the MC simulation.
I canceled the run and clicked the desired profile name directly in the list of profiles and again pressed the Create Report button. It then worked.
It seems that when ESPP gets confused about which profile to run, the error happens somewhere in the action code for clicking the Create Report button. The banner can show the change in the profile name just as it starts the MC run.
I don't consider this a big problem but you can add it to the low priority list of anomalies to track down sometime in the future. The workaround is easy -- if you note the wrong name pop up in the banner when you click the Create Report button, just abort the run and click on the desired profile name again. That seems to re-sync the profile to be run.
John
Seems unlikely to me for it to change in that routine, but I'll experiment.
Lowell,
I've seen this happen at least 20 times. At first I thought it was user error. Now I'm 100% convinced it's real. It's really minor as you can just re-run the create reports, but this does happen rarely.
Best,
Brian
Lowell,
I have found a way to reliably recreate this problem. The following sequence of actions will show the problem every time for me. I don't think it is exactly how I first encountered the problem, but this sequence behaves the same way.
1) Open ESPlannerPlus
2) Click on an existing profile (for this example, BASE)
3) Save As... to BASE CASE 2
4) double click on the BASE profile name to expand the input folders
. . . The banner will show BASE for the profile selected. . .
5) double click on the BASE CASE 2 profile name to expand its input folders
. . . The banner will show BASE CASE 2 for the profile selected. . .
6) click on the saved PDF report for BASE to show it in Adobe Reader
. . . The banner will change back and show BASE for the profile selected. . .
7) click on the Assets & Saving folder of the BASE CASE 2 profile
. . . The banner will change to again show BASE CASE 2 for the profile selected. . .
8) change the value in the Savings and checking accounts entry box
9) click on Create Reports in the ESPlanner Tool Bar
. . . The banner will continue to show BASE CASE 2 for the profile selected. . .
10) click the Create Report button of the Report Options pane
. . . The banner changes to WAIT...
. . . The banner will change back to BASE as the MC run begins. . .
The BASE profile is the one that is really running even though BASE CASE 2 was the name shown in the banner at the time you pressed the Create Report button.
As noted in the other Support Ticket I submitted, the previous saved report for the BASE profile will be corrupted if you cancel the run and have closed the existing report at any time between steps 6 and 10.
Hopefully, this will allow you to track down the logic error in the code.
John
I'll give this a try but it doesn't seem likely to produce an error. Here's why:
There are a couple irrelevant things in your description you wouldn't know about. It's important to remove irrelevant data when trying to debug something or you find yourself looking for things that you will never find.
The profile selection is 100% driven by the code that manages the Family/Profile tree, even if you manipulate it using the menu. So, adding/changing data on a page doesn't matter, opening the PDF doesn't matter. There's a routine which confirms that the data being changed matches the profile that's been selected and loads the ID of the profile in use into a data structure available throughout the program. This is a key point.
The "confusion" can occur when there are two profiles displayed on the tree an you jump back and forth between them, especially if on profile is in family "Smith" and the other is in "Jones." If there's a page displayed from the tree for profile "A" in Smith and "B" Jones. If you have "Special" opened on the Smith tree (Smith/A/Special) and click Jones/B/Special, the Smith/A/Special page will close and then Jones/B/Special opens. In fact, if you click Special again on Smith/A/Special, it will close and re-open Smith/Jones/Special (a good way to test if data gets saved properly). Each time any page opens there's a check to confirm no data conflicts.
Since the Computation page is outside of the pages in the profile tree, even though the checks are the same, I have seen examples, again when jumping from Smith/A to Jones/B, that the computation page displays data from Smith/A when I thought I was on Jones/B. Somehow, the code that makes the changes of the ID doesn't run. That's why I added the display of the profile as Smith/A to the computation banner, for my debugging as well as a double-check this hasn't occurred.
It seems impossible to me that the code that's showing the name/profile could somehow switch to a previous name/profile when the computation begins.
So, I will have to expand my debugging to include some "non-relevant" data (usually that's obscure Windows OS stuff at this point). We'll see.
Lowell,
Those are reasonable arguments and you know the entrails of the code involved. I can only say that the above sequence reproduces the problem and describes the banner messages exactly for me. I have only the ESPlannerPlus version so all profiles are part of the same family.
Perhaps someone else can try the sequence to see if they get similar results. If it turns out that my case is the only one that can reproduce this, I'll upload my database to the support ticket for you to look over.
John
I tried this quickly and I don't see an error following your steps.
With respect to step 10:
10) click the Create Report button of the Report Options pane
. . . The banner changes to WAIT...
. . . The banner will change back to BASE as the MC run begins. . .
Are you saying that the error is that the banner is wrong? or the report produced is wrong?
I didn't see this behavior, either
Lowell,
Thanks. I guess I'll upload my DB to the support ticket for you try with my data.
In answer to your question, after step 9, the banner shows the profile I intended to run. After pressing the Create report button in step 10, is when the profile name shown in the banner changes to show the wrong profile being run. In between, the banner briefly shows "Wait...".
So, the profile that gets run is the wrong one in the sense that it is not the profile name showing at the very moment I press the Create Report button. It changes as soon as I press that button.
I assume you tried the exact same sequence as I wrote and didn't eliminate any apparently extraneous steps (per your comment earlier).
If anyone else has seen this problem and can recreate, it would be helpful. In the meantime, I'll send Lowell a copy of my database to try a recreate on that.
John
Yes, I followed your steps, just in case. I can't see how the database will matter, either, but I'll give it a go.
I'm confused by this:
So, the profile that gets run is the wrong one in the sense that it is not the profile name showing at the very moment I press the Create Report button. It changes as soon as I press that button.
FYI, once the computation is started, the CE (computation engine) takes the input file and runs espbasic.exe. If Monte Carlo or upside are being run, this is a secondary process. The CE leaves the report data after finishing and then the report code runs (Excel or PDF or both) based on whatever data is found in the CE report directory.
So, if the banner changes that implies that the banner is just behind the curve and that the actual profile that got run is different. Which is it? When I looked this following your steps I also checked the log file to see which profile was being sent to the CE ( you can tell from the file name). I didn't observe a mistake there.
It seems unlikely that the page that starts the CE would change AFTER you start a report.
Computers a really a pain in the neck, huh?
Lowell,
My written descriptions are not getting across. Sorry. Yes, computers can be lots of "fun" at times. I've been working at understanding subtle bugs for over 38 years and still have little insight into how even impossible things can find a way to happen. I usually just blame it on Murphy.
To better illustrate exactly what is going on, I made a short screen shot video of the bug. I will upload it to the support ticket. You can the see exactly what happens on my system.
John
To better illustrate exactly what is going on, I made a short screen shot video of the bug. I will upload it to the support ticket. You can the see exactly what happens on my system.
How come no music with the video? :-)
I got it - I think I see how it may happen. I'll make an update available for you to test