nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

FTA: Delete Tree from Model Browser

medini_1036016653

Dear medini, as of v2019 R1.1 I am unable to find a way on how to delete a fault tree. When I select an event (which contains a tree below) in the model browser, then right-click -> "delete" merely deletes the topmost item. The remaining items of the tree (events, gates) remain present in the model. On the contrary, deleting a folded element (double-click) from a diagram using "delete from model" does in fact also delete the nested items. Please consider to introduce an additional entry in the context menu of the model browser to also delete nested elements. Thank you! Best regards Peter

Find more posts tagged with

medini

medini legacy

Accepted answers

All comments

medini_1036016653

There exists a setting "Delete Children with Parent". Unfortunately (2019R1.1) it does not do what it claims, when detelting a tree from the model browser.

medini_1024120963

Hi Peter, are the events which haven't been deleted transfer gates? BR Joël

medini_1036016653

Hi Joel, no, this behavior is present in general, independent of the nested elements' type. Please go ahead and give it a try yourself. I have two further observations to my issue of (efficiently!) deleting an event/gate together with its subtree, made on v2020 R1: - the subtree menu in the setting (accidently?!) moved one level up: - when the setting "Delete Children with Parent" is checked then I can delete a subtree from within the diagram, even when it is not first collapsed, but it takes a (very) long time for large trees: -- the right-click itself takes much longer, once this setting is activated -- the operation "delete from model" takes in the order of minutes for a tree containing about 500 to 1000 objects Please give it a try yourself with the example project I made available to Michael Sodel and Krasimira a couple of weeks ago. I'm reporting this against the most recent version of medini to emphasize the perfomance limitations that also this latest release exhibits. Thank you for looking at this. Best regards Peter (listening to his loudly spinning laptop's fan...) PS: I just had to kill the corersponding v2019R1.1 task, once it maxed out 10GB of RAM that I made available to Eclipse. It simply stalled... :-(

medini_1036016653

Sorry for
bothering again. Even with v2020R1 I seem to be unable to delete the tree in an
efficient manner. It seems the medini process isn't even working (hard) on the
task: 8% CPU utilization

In case you wonder about my laptop's hardware:

https://ark.intel.com/content/www/de/de/ark/products/134899/intel-core-i7-8850h-processor-9m-cache-up-to-4-30-ghz.html

-> 6 Cores / 12 Threads

100% / 12 Threads = 8,33 %/Thread -> hm

It seems that medini is mostly making use of single
threaded calculation/operations.

Now I'm having the practical issue of deleting a tree
:-) Admittedly it got created using a script, but it actually only about 1/30th
of the tree I intend on generating Monday. Would you please be so kind and get
in touch with me?

I try to supply another stripped-down example
project for you to test and will attach it here.

medini_1036016653

With the weekend approaching I took a last resort measure, googled for heap settings that could be applied and arrived at -XX:+PrintGCDetails
-XX:+AggressiveHeap The aggressive heap (https://docs.oracle.com/javase/8/docs/technotes/tools/windows/java.html) surprisingly did the trick! I tested both v2020R1 and v2019R1.1. Oracle states: " Enables Java heap optimization. This sets various parameters to be optimal for long-running jobs with intensive memory allocation, based on the configuration of the computer (RAM and CPU). By default, the option is disabled and the heap is not optimized. " I'm no expert on Java. Could you please clarify, if further options might make sense to set, e.g.: -XX:+AggressiveOpts
-XX:+UseLargePages (only Windows Server 2003?!)

-XX:+UseParallelGC -XX:+UseParNewGC

medini_1036016653

Attached you find a stripped down MPRX file v2020 R1 that helps demonstrating the described issues. Please refer to FTA models "a) …" and "b) …". Best regards Peter

medini_1036016653

As of v2020R2 this issue is basically still valid, but as a viable workaround I in the meanwhile created a script to delete a selection of trees from model browsers via script "FTA/deleteFTATree.js".