Clipping status is not saved in saved views

[obscureed]

In SMV6.7.18 (corresponding to FDS6.7.7), the settings in the Clipping dialog would be saved with a saved view. Selecting the view would re-apply the Clipping settings (or remove any clipping if the saved view had no clipping). This behavior seems to have changed in SMV6.7.21 (corresponding to FDS6.7.9). Now clipping status appears not to be re-applied when a saved view is selected. Is this deliberate? Is there any way to save multiple clipping states, to match saved views?

The previous behavior was useful, so I regard the new behavior as an issue. (In the previous behavior, there was sometimes a conflict: if a saved view without clipping has "Apply at startup" active, but clipping is active when "Save settings" is pressed, then does the user expect clipping to be active or not when smokeview is restarted? I encountered this frequently, and was slightly confused when clipping was active -- I expected all attributes of the saved view to be applied, including its clipping status. But no problem; I learned to not save settings with any clipping active.)

The previous behavior did have a problem that the Clipping dialog box would not display the reapplied settings. I think I raised this as an issue, though I cannot find it now. The newer smokeview is an improvement in that respect.

[gforney]

I'll take a look

…

On Mon, Oct 10, 2022 at 9:43 AM obscureed ***@***.***> wrote: In SMV6.7.18 (corresponding to FDS6.7.7), the settings in the Clipping dialog would be saved with a saved view. Selecting the view would re-apply the Clipping settings (or remove any clipping if the saved view had no clipping). This behavior seems to have changed in SMV6.7.21 (corresponding to FDS6.7.9). Now clipping status appears not to be re-applied when a saved view is selected. Is this deliberate? Is there any way to save multiple clipping states, to match saved views? The previous behavior was useful, so I regard the new behavior as an issue. (In the previous behavior, there was sometimes a conflict: if a saved view without clipping has "Apply at startup" active, but clipping is active when "Save settings" is pressed, then does the user expect clipping to be active or not when smokeview is restarted? I encountered this frequently, and was slightly confused when clipping was active -- I expected all attributes of the saved view to be applied, including its clipping status. But no problem; I learned to not save settings with any clipping active.) The previous behavior did have a problem that the Clipping dialog box would not display the reapplied settings. I think I raised this as an issue, though I cannot find it now. The newer smokeview is an improvement in that respect. — Reply to this email directly, view it on GitHub <#1455>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC6UCRUPTPGHGYA75K37S7LWCQMQNANCNFSM6AAAAAARBLTEWA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

-- Glenn Forney

[gforney]

is this still an issue?

[obscureed]

It is still an issue in the 6.8.0 release.

• For example, in any smokeview session: save a view with no clipping; save a different view with clipping; reapply the first saved view. At the end of this, if clipping is still active, then the clipping status of the first view has not been reapplied, and this is an example of the issue.

I've tried the test version (possibly the one mentioned in #1600) -- that is,
SMV-6.8.0-378-g9f0749d 2023-Jul-02 21:42
and this seems to have good behaviors:

• Reapplying a saved view also reapplies clipping status. This includes no clipping, and different types of clipping (blockages-and-data, blockages-only, data-only) are saved per view.
• The clipping status of the "Apply at startup" view overrides clipping status defined when "Save settings" was saved.

So the test version looks good to me. Two small niggles:
(1) Suppose a view (saved or unsaved) has clipping, and is replaced by reapplying a saved view with no clipping. In recent release versions, the most recent clipping values are visible but inactive in the clipping dialog box, and this can be very convenient. However, the test version does not do that. The inactive clip settings that were present when the view was saved are reapplied. I guess occasionally this might be a convenient behavior (though for me it would be rare), to have a separate set of potential future clips associated with each view, rather than being offered the most recent. However, if the saved options are the same as the defaults, and if the defaults can be restored somehow [see next niggle], then the most recent values are more likely to be useful, for me at least.
(2) In the release version (and many older versions), if you type a nonsensical coordinate into a clipping dialog box, then it fairly quickly gets replaced with a more sensible default value, which is the bounding value of the model. For example, if you type 999 into the maximum-x input box, and your model only extends to x=23., then the 999 is replaced with 23 fairly quickly (that is, the next time that the input state is processed). This can be useful for me when I have forgotten the bounds of my model -- I type 999, prod the system somehow, and get a reminder of the upper bound. In the test version, this does not seem to occur -- the nonsensical 999 persists (even into a saved view). One way around this would be to have a Reset button; but the previous behavior of replacing a nonsensical version with the bound (which has the same non-effect anyway) was convenient. (Apart from anything else, it allows the user to reset individual values, rather than wiping out all 6 at once.)

For me, those two niggles are much less bothersome than the usefulness of associating clipping with each saved view. So, if I'm offered the choice, I would take the test version.

Thanks for your efforts! Ed.