| Author | Message | |||
     Chris Bailey (c_bailey) Junior Member Username: c_bailey Post Number: 3 Registered: 01-2010 |
In the attached demo, I think the "name = CONST ARRAY ( value_1 , value_2 ... value_n )" definition does not seem to give an array that is constant (ie computed when the script is parsed, and never recomputed). I think it works like the ordinary "name = ARRAY (value_1 , value_2 ... value_n )" and the "CONST" has no effect. But, "name = ARRAY ( CONST(value_1) ,CONST( value_2) ... CONST(value_n ))" does seem to work, as it also should. This demo attempts to do a Monte Carlo simulation. In this simple staged problem there is a fixed rectangular background region, and a circular region written on top of it. The circle should be at random heights but always the same diameter. A potential function for diffusion makes the potential near one corner depend on the height of the circle, because it is also a source for the stuff that is diffusing. In each stage the circle should be at a different, random height. An "export" modifier saves a history of the heights and the potentials near the corner. The first definition is for n = how many trials to run (and how many stages). In the second DEFINITIONS section an array is defined with n elements and hopefully filled with random numbers, only once, so multiple references to for example the 5th element return the same random number. Later the array gets indexed by [stage], to always return the same thing inside a given stage. Putting const(random(1)) in each array element works (it is labeled "Style A" and is now how the script runs). What seems wrong is that defining a CONST ARRAY for: random(1), which is labeled "Style B", seems to get recomputed on multiple references. In other words, it seems to act like the same thing written without the "CONST", which is labeled "Style C". Try commenting out "A" and uncommenting either "B" or "C". I see "A" works but "B" and "C" fail the same way. I think "B" should work like "A", and only "C" should fail. If the array is being recomputed, you will see the size of the circular region changing between stages, because "start (0.5,height+0.1) arc(center=0.5,height) angle=360 close" is getting two different values for the two instances of "height". This is wrong. Why does this occur for "Style B"? Or did I just make some dumb mistake? Thanks!
| |||
| Marek Nelson (mgnelson) Moderator Username: mgnelson Post Number: 178 Registered: 07-2007 |
There does appear to be a discrepancy between the behavior of CONST ARRAY and the documentation. For now, use your definition that has the CONST inside the array definition and we will look into finding out whether the documentation is wrong or if there is an error in the CONST ARRAY implementation. Thanks for letting us know. | |||
| Chris Bailey (c_bailey) Member Username: c_bailey Post Number: 4 Registered: 01-2010 |
Thank you. Also, the behavior of random() does not seem to agree with the documentation. If I do not specify a seed, filling an array with random() causes groups of 4 or 5 or so sequentially equal values. I suspect random() without random_seed=# uses clock reads, and filling an array with it calls it too quickly for the clock to change (meaning it is evaluated faster than the clock is ticking). What do you think? | |||
| Marek Nelson (mgnelson) Moderator Username: mgnelson Post Number: 179 Registered: 07-2007 |
Readers should note that most of this pertains only to scripts that use RANDOM values and CONST... Some facts that effect FlexPDE behavior : a) A normal staged problem will not reparse the script file at each stage, but one with a staged geometry will. b) A problem is considered having staged geometry if the selector STAGEGRID is on or if some point in the domain references STAGE. c) When a script file is reparsed, all random numbers and const values will be regenerated. RANDOM --------------------- FlexPDE v6.11 reinitializes the random number generator whenever the script file is reparsed. So if there are two staged geometries within one second, the generator seed is the same. We have fixed v6.12 to initialize the random generator only when you open the file. (Your array has n elements that are all the same - see 2 below.) CONST ------------------------ The intention of the use for CONST in any problem is that the value is not reevaluated on each occurrence. So when there is a random element, it stays constant across multiple evaluations. e.g. If you define "height = CONST(RANDOM(1))" then height is always the same number within a run. If you define "heights = ARRAY for i (1 by 1 to n) : CONST(RANDOM(1))" this generates an array that contains all the same elements. If you plot this array on an ELEVATION, you will see that this is true. An element of a CONST ARRAY should be constant. e.g. if you define "heights = CONST ARRAY for i (1 by 1 to n) : RANDOM(1)" and "height = heights[3]" then all references to height should give the same number, not a random number. This aspect malfunctioned in v6.11 and has been fixed in v6.12. WHAT I SUGGEST FOR YOUR SCRIPT -------------------------------------- So for your study, I wouldn't use an array at all (since your definition of height references STAGE, it will reparse the script and regenerate the array anyway...) Just use a constant random number for height and turn on the STAGEGRID selector (to force regeneration of the value at each stage). See the attached script.
You may see repeated heights in v6.11, so you need to ignore them or use v6.12. The other possibility on v6.11 is to use the AUTOSTAGE=OFF. This will prompt you before each stage, causing a slight computation delay and the seed will likely be different. I put this in the attached script. Also be aware that the use of RANDOM_SEED will give you the same sequence of random numbers every time. Sometimes you want that sometimes you don't. A formal release of v6.12 should be posted within a couple of days. In the meantime there is a Windows 32-bit prerelease available at www.pdesolutions.com/download/xfpde612x1win.exe | |||
| Chris Bailey (c_bailey) Member Username: c_bailey Post Number: 5 Registered: 01-2010 |
Thanks for this. I created a simple example, and happened to use geometry that is staged, but didn't mean to conflate random number generation with geometry staging (though it makes it easy to see while it runs that rereferencing "height" gives different values). What I really want is to be able to define arbitrary parameters for use anywhere - DEFINITIONS, SELECT values, geometry, boundary conditions, even plot modifiers - and do it in staged problems so that they each have a new value for each stage, but the value doesn't change within a stage. I also don't necessarily want to reinitialize the grid in a study that doesn't stage the geometry. I think this is all possible, either the way I did it, or the way my "Style B" would do it using V6.12. Thank you for the 6.12 prerelease! |
Demo