This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Calculated Trace vs Water Quality Batch Run discrepancy

I used two methods running the trace analysis to determine the water source passing through our sampling stations. The results from running each scenario separately are very different from the Quality bath run. I am not sure why and how to fix the problem. I used Calculated trace % to color code pipes that have water coming from the targeted tracing element. 

Parents
  • Hello Michael,

    Can you provide a bit more detail on the steps you are taking to make this comparison? Are you saying that you are running two separate, regular trace runs (one for each of two sources), and then running a water quality batch run with the same two sources? Are the same calculation options being used in the cases you are comparing? (such as the run duration, hydraulic timestep and water quality timestep)

    Do you happen to be using an older version? You will see a note in this article about a known issue that sounds similar to what you describe, when using older version 10.00.00.55. You can check your version under File > Help > About. The latest is currently 10.03.01.08.

    If this does not help, please provide a copy of the model for review, along with the steps to reproduce and the values that you are seeing on your end (that you are comparing). 


    Regards,

    Jesse Dringoli
    Technical Support Manager, OpenFlows
    Bentley Communities Site Administrator
    Bentley Systems, Inc.

  • Good Morning Jesse, 

    I just uploaded the model. Essentially, I created a scenario with different trace alternatives ( sources) to find out which source passes through the sample stations which can be found in the symbology.  Then I used time = 168 hr to find out which sample station has 0% calculated trace.

    However,when I used the batch quality tool to run the same scenario with the same tracing elements (sources) but the trace % results are different than the method I used above.  Both methods have the calculation option set to 168 hr EPS .

    And I have the latest version.

    Thank you 

  • Hi Jesse, 

    I am looking at scenario: Winter operation -->  yellow Trace (8.3MGD) --> Brookside, At time 168hr , I used the Calculated trace % (Element symbology -->PIPE) near the 2020 sample site ( Element symbology --> Junction)  to determine which sample site are cover by the brookside source. Let me know if that clarifies my question. 

    Thank you

  • Apologies for the delay; it took me some time to decipher where to look in the model and that "2020 Sample" refers to the selection set of junctions.

    When opening the model, the currently active scenario was "Holly". If I change it to "Brookside" (a child of the "Yellow Trace (8.3MGD)" scenario) and compute a trace run, the results seem to match what I see for the Brookside trace source in the water quality batch run. However, I was unclear on how you were using element symbology to observe the trace values, so what I did was filter the junction table on the "2020 Sample Site" selection set and add the max trace result field. Below shows a comparison of the max trace from the "Brookside" scenario run (left side) to the exported results for the Brookside trace source in the WQ batch run tool (right side):

    Can you please try the same ton confirm whether you are seeing the same values in the Flextable for the result field "Trace (Maximum)"?

    As for the element symbology, I think you might be looking at the color of the pipes next to the "2020 sample site" junctions to determine what the max trace% is. If so, there are a couple of problems with this approach that may be misleading you into thinking that the results are different from the WQ batch run:

    1. The field that you have color coded is "Trace (Calculated)" which is the trace at the specific timestep you're looking at. The calculated trace value at the end of the simulation is not necessarily equal to the max trace, and I think you may be looking at the max trace result in the WQ batch run.
    2. The first color in the pipe trace color coding definition has a value of exactly 0% with a color of gray. This means that the calculated trace% needs to be exactly zero or less to show gray. However if you add some decimal precision to the max trace results (or trace results at the last time step) you will see that they are not exactly zero, possibly in part due to numerical noise. Rounding will cause them to show as "0" if the decimal precision is set to zero. So, it is better to change that first row in the color coding definition to something slightly more than zero to prevent numerical noise. For example if I set it to 0.1% then the colors of the pipes next to the nodes that have a max trace of zero show in gray as I think you are expecting. Here are the max trace% values with a decimal precision of 4, where you can see that 18 and 22 are the only ones with exactly zero max trace:

    There are some slight differences in the setups which may or may not contribute to other differences:

    1. The WQ batch run uses "Yellow Trace (8.3MGD)" as the representative scenario, which uses a different calculation option set than the scenario "Brookside" (a child of the "Yellow Trace (8.3MGD)" scenario) which has a different simulation start date.
    2. The WQ batch run uses junctions for the trace source whereas the normal trace runs use nearby reservoirs

    If this does not help, please provide some additional details on the steps you are taking to observe the trace values, and perhaps some screenshots (so I know I am looking at the right thing).


    Regards,

    Jesse Dringoli
    Technical Support Manager, OpenFlows
    Bentley Communities Site Administrator
    Bentley Systems, Inc.

  • Hi Jesse,

    Thank you for your help. However, I used your method and applied to multiple scenario and appear to have the same discrepancy issue. I ran the basic scenario of winter operation- parkway trace and below is the result using symbology (left) and water quality tool (right side) 

    I made sure that they are using the same tracing junction. I shorten the EPS using 48 hr trace study instead for verification purposes.  

  • Hi Michael, you mentioned "parkway trace" but that was not what I had looked at previously and I do not see a scenario by that name. Perhaps you meant the "Parkway" scenario that is a child of the "Yellow Trace (8.3 MGD)" scenario? See below.

    Would you be able to record a short video (and upload privately using the private method described here) clarifying the exact steps you are taking? I suspect that the confusion here is due to differences between what you are doing and what I tried to do.

    I do see that you appear to be using the latest version, 10.03.01.08. There is a patch available for that version but from reviewing the patch notes, I do not see anything that I feel would be related to these calculations. In the event that we confirm that we're doing the same thing and seeing a different result, I can look into providing the patch just in case it is related. If you have made changes to the model since the copy that you had last provided, please also upload the latest revision.


    Regards,

    Jesse Dringoli
    Technical Support Manager, OpenFlows
    Bentley Communities Site Administrator
    Bentley Systems, Inc.

    Answer Verified By: Sushma Choure 

  • Hi Jesse,

    It took me a few days but they are matching and working now. Thank you for providing me with detailed instructions. 

    Best,

Reply Children
No Data