I want to add a force field that depends on the atom possition. I have tried to compute the atom position, the use that as a variable and then, set the force field but I get the messege:
ERROR: Variable name for fix addforce does not exist
the code I have tried is:
variable a equal c_X
variable extforce equal ${maxforce}*step/${eqrun}*a
fix externforce A addforce v_extforce 0 0
You need use an atom-style variable if you want it to vary depending on atomic position. I don't know what any of your other variables are, but as an example, this adds a y-component of force as a function of the x-position:
variable addfx atom x*0.2
fix externforce all addforce 0. v_addfx 0.
The error you're getting means you need to "use" the variable first, i.e. output it using the thermo_style command.
Related
I am currently working on a script where within a function, key-value pairs are being added to a dictionary x - consider x as a single dictionary of different inputs used to query data, and different key-values are appended to this depending on certain conditions being fulfilled.
However, when I load in the script into my session with some new assignment logic added, I am hitting a 'constants error. This is despite all assignments being kept to this dictionary x. When these two new assignments within x are commented out, the script will load in successfully.
I know the 'constants error usually refers to the max number of constants within a certain scope being exceeded, but surely this shouldn't be happening when all assignment is happening within this dictionary x. Is there a way to get around this? What is causing this issue?
I think you are trying to do too much in one function. I think you are indexing or assigning values to the dictionary with too many constants. Below code will return the constants error:
dict:(10 + til 100)!til 100
value (raze -1_"{","dict[",/:(string[10+til 97],\:"];")),"}"
// with til 96
{dict[10];dict[11] ... dict[104]}
It's the code that is indexing the dictionary is causing the issue rather than the dictionary itself.
I have a script Function.m such that for example, when I write TEST=Function(1,2), I have TEST.x1=4 and TEST.x2=[5,6,7]. I want to use fsolve to help me find input. To be precise, I want to define a function, say a=#(y)Function(1,y)-4 so that when I use [z,vector]=fsolve(#(y)a(y),5), matlab can help me to obtain z=2 and vector=[5,6,7].
I would like to solve it by defining the same structure New_Function.m as Function.m such that it returns x1 values, i.e., TEST=New_Function(1,2) gives TEST=4 only. Then I write new_a=#(y)New_Function(1,y)-4 and solve z=fsolve(#(y)new_a(y),5) and define new_vector=Function(1,z) so that I can access new_vector.x2.
I want to know if it is possible to do my task without defining a new script or amending the content in the existing script. How to write code?
Since Matlab does not allow further referencing the result of a function call, you may need to help yourself with getfield. In your example (provided I got it right), it would be something like New_Func = #(y) getfield(Function(1,y),'x1'). This would take one scalar and return one scalar, i.e., New_Func(y) gives the field value of the struct returned by Function(1,y) associated to the field x1.
In matlab, I stored every line I plotted like so:
app.cplxPlot(app.cplxPlotNumber)= plot(app.UIAxes[app.var.cplx(1);app.var.cplx(1)],[50;250], 'g');
To make things generic, it is as if I did this:
cplxPlot(location)=plot(app.UIAxes,[cplxPlot(1);cplxPlot(1)],[50;250],'g');
This basically stores a bunch of vertical lines. I want to now delete the line with a certain x value. In the command line of matlab, I did this simple if loop to see if my first plot has the x value of 20, and it worked.
if length(find(cplx1Plot(1).XData==value,1,'first'))==1
disp('wow')
end
But, in app designer, the exact same code :
if length(find(app.cplx1Plot(1).XData==value,1,'first'))==1
app.Label.Text='wow'
end
would display the error: "Dot indexing is not supported for variables of this type." Can someone tell me what I am doing wrong? It worked perfectly in a matlab script, but not on app designer and I am not sure why.
Follow up: I just used the class function, and apparently my vector is storing doubles in app-designer, but it stores class in regular matlab... I have no idea why the elements in the vector would ever be a double.
Follow up 2.0: Apparently, if I access a property to store a line, it is stored as a double, but if I choose to make it a local variable instead, it would be a line. I need this to be a property/global variable and don't get why in the world it would ever be stored as a double...
For instances, bob stores doubles in this scenario :
bob(1)= plot([.005;.005],[100;200],'g')
app.Label.Text=string(class(bob(1)));
But, bob stores doubles in this:
app.bob(1)= plot([.005;.005],[100;200],'g')
app.Label.Text=string(class(app.bob(1)));
For context, I declared bob in my properties like this:
bob
i see that fix documentation says:
http://www.minizinc.org/doc-lib/doc-builtins-reflect.html#Ifunction-dd-T-cl-fix-po-var-opt-dd-T-cl-x-pc
function array [$U] of $T: fix(array [$U] of var opt $T: x)
Check if the value of every element of the array x is fixedat this point in evaluation. If all are fixed, return an array of their values, otherwise abort.
I am thinking it can be used to coerce a var to a par.
Here is the code.
array [1..num] of var int: value ;
%% generate random numbers from 0..num-1, this should fix the value of the var "value" or so i think
constraint forall(i in index_set(value))(let {int:temp_value=discrete_distribution([1|i in index_set(value)]); } in value[i]=trace(show(temp_value)++"\n", temp_value));
%%% this i was expecting to work, as "value" elements are fixed above
array [1..num] of int:value__ =[ trace(show(fix(value[i])), fix(value[i])) | i in index_set(value)] ;
But i get:
MiniZinc: evaluation error:
with i = 1
in call 'trace'
in call 'fix'
expression is not fixed
My questions are:
1) I think i should expect this error as minizinc is not sequential execution language?
2) Examples of fix in user guide is only where output statement is used. Is it the only place to use fix?
3) How would i coerce a var to a par?
By the way I am trying this var to par conversion because i am having problem with array generator expression. Here is the code
int:num__=200;
int:seed=134;
int: two_m=2097184;
%% prepare weights for generating numbers form 1..(two_m div 64), basically same weight
array [1..(two_m div 64)] of int: value_6_wt= [seed+1 | i in 1..(two_m div 64)] ;
%% generate numbers. this dose not work gives out
%% in variable declaration for 'value6'
%% parameter value out of range
array [1..num__] of int : value6 = [ discrete_distribution(value_6_wt) | j in 1..num__];
In the MiniZinc language the difference between a parameter and a variable is only the fact that a parameter must have a value at compile time. Within the compiler we turn as many variables into parameters as we can. This saves the solver from having to do some work. When we know that a variable has been turned into a parameter, then we can use the fix function to convince the type system that we really can use this variable as a parameter and see its value.
The problem here however is that fix is defined to abort when the variable is not fixed to one value. If no testing is done, this requires some (magic/)knowledge about the compilation process. In your case it seems that the second array is evaluated before the optimisation stage, in which all aliasing is resolved. This is the reason why it does not work. (This is indeed one of the things that is a consequence of a declarative language)
Although fix might only be used in the output statements in the examples (where it's guaranteed to work), it is used in many locations in the MiniZinc libraries. If we for example look at the library that is used for MIP solvers, there are many constraints that can be encoded more efficiently if one of the arguments is a parameter. Therefore, you will often see that the a constraint in this library first tests its arguments with is_fixed, and then use a better encoding if this returns true.
The output statement and when is_fixed returns true will both give the guarantee that a variable is fixed and ensure that the compilation doesn't abort. There is no other way to coerce a variable to a parameter, but unless you are dealing with dependant predicate definitions, you can just trust the MiniZinc compiler to ensure that the resulting FlatZinc will contain a parameter instead of a variable.
For example I have a 1*30 structure a.field, when I type a(:).field in command window it just iteratively display a(1).field, a(2).field,... However, when I was trying to assign a(:).field to another variable b, what b get is just a(1).field.
BTW, if I attampt to pass a(:).field to a function, Matlab just throws an error "too many input arguments".
What is the mechanism behind? My guess is that matlab threat colon equivlant to the first element during assignment, is that true?
You need to add brackets, otherwise matlab don't understand that your trying to store an array:
b = [a(:).field]
Another option that provide similar result:
b = horzcat(a(:).field)