I have written in model using Alloy. However for certain conditions running the predicate to find an instance is failing and it says that no instance can be found. I tried increasing the bound to about 16 instances, yet it does not find any instance.
Is there any way I can debug this so that I can see which facts are failing which is causing Alloy not being able to find an instance?
Thanks !
If you change the default sat solver to minisat with unsat core, then it will be possible to highlight the constraints that can't be satisfied in a same instance.
Another possible solution is to comment your constraints one by one until analysis yield an instance hence pinpointing which constraint might cause trouble.
For a more specific answer, please share your model.
Related
I'm currently playing around with predicates in Alloy. I know that I can use assert and check statements to confirm that my model is working as it should. However, is there any way to check that a predicate I have created has done what I expect? Or do I just have to show the instances and search through them manually?
Just say what you "expect", and set it up as an assertion. Unfortunately, Alloy does not currently have a mind-reading command :-)
I would like to Dimension the family instances. What is the reference I should be provided while creating dimension.
I have tried with several approaches but the dimensions are not getting deleted when I delete the family instances. This means that, the dimensions are not getting attached to the family instances.
Please help.
Have you found a way to address this manually through the user interface? That is mostly the best place to start when tackling a Revit API task. If you can solve it through the UI, the chances are good it can also be automated. If no UI solution is found, automation is mostly impossible as well.
I would analyse the exact differences caused in the Revit database on the elements involved and their parameters by executing the manual modification. Once you have discovered exactly what is changed by the manual UI interaction, you can probably replicate the same changes programmatically through the API. Here is a more exhaustive description of how to address a Revit API programming task:
http://thebuildingcoder.typepad.com/blog/2017/01/virtues-of-reproduction-research-mep-settings-ontology.html#3
I'm learning Alloy, and can use check and run individually. But, when I have them both in, it seems that the check is ignored. How do I execute both the check and the run?
To expand the question:
If I have a run, do I even need a check? Won't it automatically check all my assertions? Or is the goal of the check not only to check the assertions, but to intentionally and exhaustively (within the scope) search for a counterexample?
Is the goal of run only to find an instance that meets the predicate? Or is there another usage of run?
Perhaps check should be search-counterexample and run should be search-example?
Is Alloy limited to one search (check or run) for execution? If so, is the best practice to simply comment out all but one check/run, and uncomment out one at a time?
How do I execute both the check and the run?
You don't. You do one at a time.
Given two predicates P1 and P2, it's always possible to define a new predicate to combine them however you want (with and, or, and not, =>, etc., etc.), and doing so can be very helpful sometimes.
Given a predicate P and an assertion A, however, there may be less need to check them at the same time than you think. If the assertion A holds for a given scope, then it holds whether predicate P is satisfied or not. If it always holds in that scope, then you don't need to check it in addition to P, when seeking an instance of P. (It will hold whether you check it or not.)
If I have a run, do I even need a check? Won't it automatically check all my assertions? Or is the goal of the check not only to check the assertions, but to intentionally and exhaustively (within the scope) search for a counterexample?
An assertion is checked only when you ask the Analyzer to check it. The Analyzer checks the assertion precisely (and only) by looking for counter-examples.
In this, assertions differ from Alloy facts, which are always true by definition (or: by fiat) and need not be checked. (And more than that: they cannot be checked: since a counter-example is impossible, there is nothing for the Analyzer to look for, and there is no verb by means of which you could request that the Analyzer look for it.)
The difference between facts and assertions is worth thinking about.
Facts express constraints on a model; assertions don't. Informally, an assertion can be thought of as a suggestion (or claim) that a given constraint is already imposed on the model, that it follows logically from what has already been said. Assertions which state the blindingly obvious are useful, because checking them can draw our attention to situations where those blindingly obvious things are not in fact true. Assertions which state non-obvious consequences of the constraints in a model are also useful, in a different way, drawing our attention as readers to consequences we might have overlooked.
Facts can be useful too, as simple ways to restrict the model to situations we are interested in. But since they are always true, whether redundant with other constraints or not, facts have fewer opportunities to surprise us. (The most frequent surprise I associate with facts is the unwelcome discovery that my formulation of a fact has made it impossible to find any instances of the model. Over time, I have come to avoid using facts wherever possible: anything I am tempted to write as a fact, I end up rewriting as a predicate.)
Is the goal of run only to find an instance that meets the predicate? Or is there another usage of run?
That's the only one this user of Alloy knows.
Perhaps check should be search-counterexample and run should be search-example?
You may have a point; find-example and find-counterexample might be clearer for new users. (I wouldn't like search here, at least not without -for.) But some users' fingers may rebel at replacing a five-character command like check with a twenty-one-character equivalent.
Is Alloy limited to one search (check or run) for execution? If so, is the best practice to simply comment out all but one check/run, and uncomment out one at a time?
Not necessary; the Execute menu gives you your choice of the command to execute.
I would like to refer to the question that can be found at this address :
Running alloy analyzers in parallel
Is there any ongoing research or conclusion reached on the decomposition of Alloy models, in order to allow a more optimal analysis of models ?
This interests me greatly.
I am very interesting in this topic too. Maybe we can think about it like this. When starting Alloy engine to solve a constraint, we can call a function from Alloy and ask it to solve one constraint. I think we can call this function in cluster mode, and ask each node to solve one constraint. Then, we can compute the subset of the results from each node. See here for example: http://alloy.mit.edu/alloy/code/ExampleUsingTheCompiler.java.html
I am not sure we can work like this, but it's worthy to think about it in MapReduce like framework.
Everything is cruisin' along just fine in an Entity (A) with a Relationship to another Entity (B). Then some of the related data (B) gets corrupted, and A can not fulfill a fault because the related thing in B is no longer available.
I would be happy just cleaning out any A records that have this problem, but don't know how to detect if the relationship is broken without the program actually throwing the error (and bombing).
Ideas?
Why code a workaround for some other bug in your program? The case you describe should be solved on the level of the "corruption", not the consequences.
In other words, you should look at your code and prevent that "some of the related data (B) gets corrupted". If you have invalid Bs, simply delete them. If your model is set up correctly, it should automatically sever the relationship with A.