Hello all,
I have modified “FLAC Constitutive Model” into a simple strain softening model and tried to run a basic UCS Test using this constitutive model.
For the basic understand of what is happening inside,
I created a variable check which stores the value of iteration for each of the grid.
The part of the code I wrote after
/* — plastic padRameter incrementation and properties update — */ is as follows:
Double dAux = 1.0 / s->getZoneVolume();
if (s->overlay_ == 2) dAux *= 0.5;
sHP_ += s->working_[Dqs] * dAux;
check_ = iteration;
iteration = iteration + 1;
if(iteration==50)
{
iteration = 0;
}
I used a Grid of 5 10 so I suppose the values that check_ should take must vary from 0 to 49 for each step and then as iteration value equals 50 it is initialised to 0
So for every step the values for all 50 values should be from 0 to 49.
When I make a DLL file, send it into FLAC plugin and then start the FLAC code of UCS Test using model example.
These are few examples of printing check which I get:
You can see that many times the values are not even incremented.
Due to this issue, I am not able to modify my desired model further. Please look over this issue if it is a bug.
I’m not sure how it is handled in FLAC2D and what exactly the scope of your variables is (e.g. is iteration registered as a property or a global variable?), but you seem to have some general misconceptions about how those constitutive model DLLs work, so maybe these comments help:
Usually there are multiple sub-zones per zone, which means that for any given FLAC zone the constitutive model is called multiple times. Therefore your “counting” might be misleading.
maybe there is also a conflict in multithreaded environments, since multiple instances may try to increase the parameter, not necessarily ordered (check by calculating single-threaded)
If you want to find out what happens exactly, you should simply debug the DLL, going step by step as the code calculates. In visual studio you can do this by Debug → Link to Process and select your FLAC code. Now you can add breakpoints and then go through your code line by line and see, how these values change. (Never done the for FLAC2D, though).
Hello Sir,
Thanks for the reply.
During my recent iterations, I got to know that for each step, the initialisation function is run a single time and the run function should run 4 times per zone(I assume it has 4 subzones).
But the order of this run function is random according to me. What I did was, I assigned a variable in initialisation and another in run function and added the iteration number by 1 to check how they are proceeded.
For the variable assigned in initialisation function, it is going in order.(Let’s say the grid if 5 10, when variable is printed the number output is visible in order from 0 to 49 and even if step is increased it goes from 50 to 99 and so on).
But when I did the same for the variable in the run function. According to my logic, the values should go something like 3 7 11 etc but the values are very random and cannot understand how it is taking place in run function.
Please convey the iteration order in this run function,how is it implemented?
Also sir, one thing more regarding the debug mode,
I went to Debug->Attach to Process->Chose FLAC but how to proceed afterwards. Can you elaborate?
When using multithreading, the order of visited zones may vary. Try using program threads 1 (also before debugging) so you can better step through the code.
After (or before) attaching to the process in Visual Studio you can mark certain lines as breakpoints (click left of the line number in visual studio, a red circle should appear there). If everything worked and you run your model (e.g. cycle 1 step), the code should stop at that point and you can hover over the variables to see the values or go step by step further on with F10/F11. Please note that the DLL must be compiled with the debugging options enabled (no optimization), otherwise you may not be able to see all values.
If you are using old FLAC, tryin using ‘set multithreads off’ command to turn the multithreading off or using command ‘set thread 1’ to limit one thread for calculations.
