| |
ID |
Date |
Author |
Subject |
|
|
198
|
Fri Feb 24 10:05:38 2023 |
Alex M | Paper Symmetric Run for Reviewer | We began a new run for a symmetric bicone antenna. The purpose of this is to satisfy the most recent comments from the reviewer on the paper. We are using the same GA as for the paper with the same parameters. I will update this post soon with more details about this run. There is a run_details file attached, but please wait for me to update this post with more specifics as the version of the GA being used is less connected to the details presented in that file.
The data can be found here: /fs/ess/PAS1960/BiconeEvolutionOSC/BiconeEvolution/current_antenna_evo_build/XF_Loop/Evolutionary_Loop/Run_Outputs/2023_02_20_Symmetric_Run . |
| Attachment 1: run_details_2023_02_20_Symmetric_Run.txt
|
####### VARIABLES: LINES TO CHECK OVER WHEN STARTING A NEW RUN ###############################################################################################
RunName='2023_02_20_Symmetric_Run' ## This is the name of the run. You need to make a unique name each time you run.
TotalGens=100 ## number of generations (after initial) to run through
NPOP=50 ## number of individuals per generation; please keep this value below 99
Seeds=10 ## This is how many AraSim jobs will run for each individual## the number frequencies being iterated over in XF (Currectly only affects the output.xmacro loop)
FREQ=60 ## the number frequencies being iterated over in XF (Currectly only affects the output.xmacro loop)
NNT=30000 ## Number of Neutrinos Thrown in AraSim
exp=18 ## exponent of the energy for the neutrinos in AraSim
ScaleFactor=1.0 ## ScaleFactor used when punishing fitness scores of antennae larger than the drilling holes
GeoFactor=1 ## This is the number by which we are scaling DOWN our antennas. This is passed to many files
num_keys=4 ## how many XF keys we are letting this run use
database_flag=0 ## 0 if not using the database, 1 if using the database
## These next 3 define the symmetry of the cones.
RADIUS=0 ## If 1, radius is asymmetric. If 0, radius is symmetric
LENGTH=0 ## If 1, length is asymmetric. If 0, length is symmetric
ANGLE=0 ## If 1, angle is asymmetric. If 0, angle is symmetric
CURVED=0 ## If 1, evolve curved sides. If 0, sides are straight
A=0 ## If 1, A is asymmetric
B=0 ## If 1, B is asymmetric
SEPARATION=0 ## If 1, separation evolves. If 0, separation is constant
NSECTIONS=1 ## The number of chromosomes
DEBUG_MODE=0 ## 1 for testing (ex: send specific seeds), 0 for real runs
## These next variables are the values passed to the GA
REPRODUCTION=3 ## Number (not fraction!) of individuals formed through reproduction
CROSSOVER=36 ## Number (not fraction!) of individuals formed through crossover
MUTATION=25 ## Probability of mutation (divided by 100)
SIGMA=6 ## Standard deviation for the mutation operation (divided by 100)
ROULETTE=8 ## Percent of individuals selected through roulette (divided by 10)
TOURNAMENT=2 ## Percent of individuals selected through tournament (divided by 10)
RANK=0 ## Percent of individuals selected through rank (divided by 10)
ELITE=0 ## Elite function on/off (1/0)
#####################################################################################################################################################
|
|
|
204
|
Mon Mar 20 16:31:09 2023 |
Alex M | Installing PUEOsim | Will sent me some info on how to install PUEOsim. I attached a markdown file he sent for how to install PUEOsim. He also sent the path to pre-compiled installation of PUEOsim. Here's the path to the pre-compiled installation: /users/PAS0654/wluszczak/PUEO_shared
Here is his full message, which details that you must also run set_env.sh before running PUEOsim:
a pre-compiled version is located at /users/PAS0654/wluszczak/PUEO_shared . Inside that directory, there's a set_env.sh script that you will need to source before running anything (hopefully this works, though there's a high probability you might run into permissions issues with the dependencies).
To run PUEOsim, use the following (see here for instructions: https://github.com/PUEOCollaboration/pueoSim):
./simulatePueo -i {inputFile} -o {outputDirectory} -r {runNumber} -n {numberOfNeutrinos} -e {energyExponent}
The outputs will be root files, but it should be possible (either modifying our own version directly or with a script) to print out the effective volume to a .txt to read.
|
| Attachment 1: CentOS_7_install.md
|
#pueoBuilder Installation Tutorial
This tutorial will guide you through the process of building the tools included in pueoBuilder from scratch, including the prerequisites and any environment variables that you will need to set. This sort of thing is always a bit of a nightmare process for me, so hopefully this guide can help you skip some of the frustration that I ran into. I did not have root acces on the system I was building on, so the instructions below are what I had to do to get things working with local installations. If you have root access, then things might be a bit easier. For reference I'm working on CentOS 7, other operating systems might have different problems that arise.
##Prerequisites
As far as I can tell, the prerequisites that need to be built first are:
-cmake 3.21.2 (I had problems with 3.11.4)
-gcc 11.1.0 (9.X will not work)
-fftw 3.3.9
-gsl 2.7.1 (for ROOT)
-ROOT 6.24.00
###CMake
You can download the source files for CMake here: https://cmake.org/download/. Untar the source files with:
tar -xzvf cmake-3.22.1.tar.gz
Compiling CMake is as easy as following the directions on the website: https://cmake.org/install/, but since we're doing a local build, we'll use the `configure` script instead of the listed `bootstrap` script. As an example, suppose that I downloaded the above tar file to `/scratch/wluszczak/cmake`:
mkdir install
cd cmake-3.22.1
./configure --prefix=/scratch/wluszczak/cmake/install
make
make install
You should additionally add this directory to your `$PATH` variable:
export PATH=/scratch/wluszczak/cmake/install/bin:$PATH
To check to make sure that you are using the correct version of CMake, run:
cmake --version
and you should get:
cmake version 3.22.1
CMake suite maintained and supported by Kitware (kitware.com/cmake).
### gcc 11.1.0
Download the gcc source from github here: https://github.com/gcc-mirror/gcc/tags. I used the 11.1.0 release, though there is a more recent 11.2.0 release that I have not tried. Once you have downloaded the source files, untar the directory:
tar -xzvf gcc-releases-gcc-11.1.0.tar.gz
Then install the prerequisites for gcc:
cd gcc-releases-gcc-11.1.0
contrib/download_prerequisites
One of the guides I looked at also recommended installing flex separately, but I didn't seem to need to do this, and I'm not sure how you would go about it without root priviledges, though I imagine it's similar to the process for all the other packages here (download the source and then build by providing an installation prefix somewhere)
After you have installed the prerequisites, create a build directory:
cd ../
mkdir build
cd build
Then configure GCC for compilation like so:
../gcc-releases-gcc-11.1.0/configure -v --prefix=/home/wluszczak/gcc-11.1.0 --enable-checking=release --enable-languages=c,c++,fortran --disable-multilib --program-suffix=-11.1
I don't remember why I installed to my home directory instead of the /scratch/ directories used above. In principle the installation prefix can go wherever you have write access. Once things have configured, compile gcc with:
make -j $(nproc)
make install
Where `$(nproc)` is the number of processing threads you want to devote to compilation. More threads will run faster, but be more taxing on your computer. For reference, I used 8 threads and it took ~15 min to finish.
Once gcc is built, we need to set a few environment variables:
export PATH=/home/wluszczak/gcc-11.1.0/bin:$PATH
export LD_LIBRARY_PATH=/home/wluszczak/gcc-11.1.0/lib64:$LD_LIBRARY_PATH
We also need to make sure cmake uses this compiler:
export CC=/home/wluszczak/gcc-11.1.0/bin/gcc-11.1
export CXX=/home/wluszczak/gcc-11.1.0/bin/g++-11.1
export FC=/home/wluszczak/gcc-11.1.0/bin/gfortran-11.1
If your installation prefix in the configure command above was different, substitute that directory in place of `/home/wluszczak/gcc-11.1.0` for all the above export commands. To easily set these variables whenever you want to use gcc-11.1.0, you can stick these commands into a single shell script:
#load_gcc11.1.sh
export PATH=/home/wluszczak/gcc-11.1.0/bin:$PATH
export LD_LIBRARY_PATH=/home/wluszczak/gcc-11.1.0/lib64:$LD_LIBRARY_PATH
export CC=/home/wluszczak/gcc-11.1.0/bin/gcc-11.1
export CXX=/home/wluszczak/gcc-11.1.0/bin/g++-11.1
export FC=/home/wluszczak/gcc-11.1.0/gfortran-11.1
(again substituting your installation prefix in place of mine). You can then set all these environment variables by simply running:
source load_gcc11.1.sh
Once this is done, you can check that gcc-11.1.0 is properly installed by running:
gcc-11.1 --version
Note that plain old
gcc --version
might still point to an older version of gcc. This is fine though.
###FFTW 3.3.9
Grab the source code for the appropriate versino of FFTW from here: http://www.fftw.org/download.html
However, do NOT follow the installation instructions on the webpage. Those instructions might work if you have root privileges, but I personally couldn't seem to to get things to work that way. Instead, we're going to build fftw with cmake. Untar the fftw source files:
tar -xzvf fftw-3.3.9.tar.gz
Make a build directory and cd into it:
mkdir build
cd build
Now build using cmake, using the flags shown below. For reference, I downloaded and untarred the source file in `/scratch/wluszczak/fftw/build`, so adjust your install prefix accordingly to point to your own build directory that you created in the previous step.
cmake -DCMAKE_INSTALL_PREFIX=/scratch/wluszczak/fftw/build/ -DBUILD_SHARED_LIBS=ON -DENABLE_OPENMP=ON -DENABLE_THREADS=ON ../fftw-3.3.9
make install -j $(nproc)
Now comes the weird part. Remove everything except the `include` and `lib64` directories in your build directory (if you installed to a different `CMAKE_INSTALL_PREFIX`, the include and lib64 directories might be located there instead. The important thing is that you want to remove everything, but leave the `include` and `lib64` directories untouched):
rm *
rm -r CMakeFiles
Now rebuild fftw, but with an additional flag:
cmake -DCMAKE_INSTALL_PREFIX=/scratch/wluszczak/fftw/build/ -DBUILD_SHARED_LIBS=ON -DENABLE_OPENMP=ON -DENABLE_THREADS=ON -DENABLE_FLOAT=ON ../fftw-3.3.9
make install -j $(nproc)
At the end of the day, your fftw install directory should have the following files:
include/fftw3.f
include/fftw3.f03
include/fftw3.h
include/fftw3l.f03
include/fftw3q.f03
lib64/libfftw3f.so
lib64/libfftw3f_threads.so.3
lib64/libfftw3_omp.so.3.6.9
lib64/libfftw3_threads.so
lib64/libfftw3f_omp.so
lib64/libfftw3f.so.3
lib64/libfftw3f_threads.so.3.6.9
lib64/libfftw3.so
lib64/libfftw3_threads.so.3
lib64/libfftw3f_omp.so.3
lib64/libfftw3f.so.3.6.9
lib64/libfftw3_omp.so
lib64/libfftw3.so.3
lib64/libfftw3_threads.so.3.6.9
lib64/libfftw3f_omp.so.3.6.9
lib64/libfftw3f_threads.so
lib64/libfftw3_omp.so.3
lib64/libfftw3.so.3.6.9
Why do we have to do things this way? I don't know, I'm bad at computers. Maybe someone more knowledgeable knows. I found that when I didn't do this step, I'd run into errors that pueoBuilder could not find some subset of the required files (either the ones added by building with `-DENABLE_FLOAT`, or the ones added by building without `-DENABLE_FLOAT`).
Once fftw has been installed, export your install directory (the one with the include and lib64 folders) to the following environment variable:
export FFTWDIR=/scratch/wluszczak/fftw/build
Again, substituting your own fftw install prefix that you used above in place of `/scratch/wluszczak/fftw/build`
###gsl 2.7.1
gsl 2.7.1 is needed for the `mathmore` option in ROOT. If you have an outdated version of gsl, ROOT will still compile, but it will skip installing `mathmore` and `root-config --has-mathmore` will return `no`. To fix this, grab the latest source code for gsl from here: https://www.gnu.org/software/gsl/. Untar the files to a directory of your choosing:
tar -xzvf gsl-latest.tar.gz
For some reason I also installed gsl to my home directory, but in principle you can put it wherever you want.
mkdir /home/wluszczak/gsl
./configure --prefix=/home/wluszczak/gsl
make
make check
make install
To make sure ROOT can find this installation of gsl, you'll again need to set an environment variable prior to building ROOT:
export GSL_ROOT_DIR=/home/wluszczak/gsl/
I also added this to my $PATH variable, though I don't remember if that was required to get things working or not:
export PATH=/home/wluszczak/gsl/bin/:$PATH
export LD_LIBRARY_PATH=/home/wluszczak/gsl/lib:$LD_LIBRARY_PATH
###ROOT 6.24.00
Download the specific version of ROOT that you need from here: https://root.cern/install/all_releases/
You might need to additionally install some of the dependencies (https://root.cern/install/dependencies/), but it seems like everything I needed was already installed on my system.
Untar the source you downloaded:
tar -xzvf root_v6.24.00.source.tar.gz
Make some build and install directories:
mkdir build install
cd build
Run CMake, but be sure to enable the fortan, mathmore and minuit2 options. For reference, I had downloaded and untarred the source files to `/scratch/wluszczak/root`. Your installation and source paths will be different.
cmake -DCMAKE_INSTALL_PREFIX=/scratch/wluszczak/root/install/ /scratch/wluszczak/root/root-6.24.00/ -Dfortran=ON -Dminuit2=ON -Dmathmore=ON
Note: if you end up with an error related to compiling XROOTD, then add -Dxrootd=OFF to the original cmake command above.
Then proceed to start the build:
cmake --build . --target install -j $(nproc)
If everything has worked then after the above command finishes running, you should be able to run the following file to finish setting up ROOT:
source ../install/bin/thisroot.sh
##pueoBuilder
By this point, you should have working installations of CMake 3.21.2, gcc-11.1.0, fftw 3.3.9, and ROOT 6.24.00. Additionally, the following environment variables should have been set:
export PATH=/scratch/wluszczak/cmake/install/bin:$PATH
export PATH=/home/wluszczak/gcc-11.1.0/bin:$PATH
export LD_LIBRARY_PATH=/home/wluszczak/gcc-11.1.0/lib64:$LD_LIBRARY_PATH
export CC=/home/wluszczak/gcc-11.1.0/bin/gcc-11.1
export CXX=/home/wluszczak/gcc-11.1.0/bin/g++-11.1
export FC=/home/wluszczak/gcc-11.1.0/gfortran-11.1
export FFTWDIR=/scratch/wluszczak/fftw/build
At this point, the hard work is mostly done. Check out pueoBuilder with:
git clone git@github.com:PUEOCollaboration/pueoBuilder
set the following environment variables:
export PUEO_BUILD_DIR=/scratch/wluszczak/PUEO/pueoBuilder
export PUEO_UTIL_INSTALL_DIR=/scratch/wluszczak/PUEO/pueoBuilder
export NICEMC_SRC=${PUEO_BUILD_DIR}/components/nicemc
export NICEMC_BUILD=${PUEO_BUILD_DIR}/build/components/nicemc
export PUEOSIM_SRC=${PUEO_BUILD_DIR}/components/pueoSim
export LD_LIBRARY_PATH=${PUEO_UTIL_INSTALL_DIR}/lib:$LD_LIBRARY_PATH
Where $PUEO_BUILD_DIR and $PUEO_UTIL_INSTALL_DIR point to where you cloned pueoBuilder to (in my case, `/scratch/wluszczak/PUEO/pueoBuilder`. Now you should be able to just run:
./pueoBuilder.sh
Perform a prayer to the C++ gods while you're waiting for it to compile, and hopefully at the end of the day you'll have a working set of PUEO software.
##Issues I Ran Into
If you already have an existing installation of ROOT, you may still need to recompile to make sure you're using the same c++ standard that the PUEO software is using. I believe the pre-compiled ROOT binaries available through their website are insufficient, though maybe someone else has been able to get those working.
If you're running into errors about c++ standard or compiler version even after you have installed gcc-11.1.0, then for some reason your system isn't recognizing your local installation of gcc-11.1.0. Check the path variables ($PATH and $LD_LIBRARY_PATH) to make sure the gcc-11.1.0 `bin` directory is being searched.
If you're running into an error that looks like:
CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
FFTWF_LIB (ADVANCED)
then pueoBuilder can't seem to find your fftw installation (or files that are supposed to be included in that installation), try rebuilding with different flags according to which files it seems to think are missing.
If it seems like pueoBuilder can't seem to find your fftw installation at all (i.e. you're getting some error that looks like `missing: FFTW_LIBRARIES` or `missing: FFTW_INCLUDES`), check the environment variables that are supposed to point to your fftw installation (`$FFTWDIR`) and make sure there are the correct files in the `lib` and `include` subdirectories.
|
|
|
205
|
Mon Mar 20 17:32:42 2023 |
Alex M | GENETIS Hackathon Day 1 | Today was the first day of the GENETIS Hackathon. We are spending several days this week specifically tackling the PUEO project to get it into full form (or close to it). Here is a progress update after day 1.
Alex
I am working on the xmacro script for the ANITA antenna. Before today, we had a working xmacro script to make the geometry of the ANITA horn antenna. Now I am trying to modify it to make it 1) more true to the actual ANITA antenna (in terms of which parts are electrically connected) and 2) add in the power source and sensors so that we can get simulation results. I've attached the xmacro script here along with a picture of the geometry and some gain patterns. There are four ridges in the antenna. They are all connected by the outer walls of the antenna. However, only the ones directly across from each other are connected by a load (in this case, a power source, since we simulate as a radiator). So we have two power sources, one connected each "ridge bicone".
In making this, I have generated some gain patterns. I want to test a few cases to see if the results coming from XF seem reasonable, though I don't know what I should expect the gain pattern to look like when I've done things correctly. Here are the options I'll compare:
- Just use one "ridge bicone".
- Use two "ridge bicones" with the walls but just one power source.
- Use two "ridge bicones" without the walls and two power sources.
- Use the full form, with two "ridge bicones", walls, and two power sources.
Case (4) is the one I expect to be correct. However, when I simulate that, I get a slightly asymmetric gain pattern compared to what I expect (I expect symmetry across the "ridge bicones"). You can see from the attached image that there is a strange preference in one corner. My guess is that this has to do with which ridges are set to be ground and which are set to 1V (the potential). Feel free to ask me for more details about these figures/scripts on slack and I'll fill them in on here. I'll clean up the script and add in full test cases later this week.
The image of the antenna I attached is a bird's eye view. The green lines represent the power sources I've connected between the ridges. They do appear to overlap, but my understanding is that they are not actually affecting each other (they should just be a representation of the power sources).
The image of a gain pattern (which is 3D and also a bird's eye view) is for the case of the antenna with both power sources and the walls remaining (the antenna is still shown too, to demonstrate the asymmetry of the gain pattern). This is well outside of the frequency range ANITA cares about (83 MHz), and I haven't looked closely at the higher frequencies yet, but I still am surprised by the asymmetry. I'll update tomorrow with more gain patterns to compare.
Dylan and Jacob
Dylan and Jacob are working on the bash scripts for the PUEO loop. They are taking the parts of the bicone loop that are specific to ARA/bicones and changing them to be specific to the PUEO loop.
All the bash scripting outside of implementing the new software we’re developing should now be complete (we just need to debug when we do test runs). The new GA is implemented into the PUEO loop. We tried and failed to build a version of pueoSim on our own. Will has provided us with a precompiled version and instructions for installing it on our users as well as access to the necessary pueoBuilder repo. Jacob and Dylan are scheduled to go through the installation with him on Thursday at 4pm in his office, M2024.
We have also found that peuoSim currently only outputs root files. So, we will need to create a conversion script or modify pueoSim for when we implement it into the loop. Currently, using IceMC looks to be the easiest way to get a test run going. For the next steps, we have a plan for making IceMC read in a variable file path name to avoid recompiles and issues with parallelization (Alex has given us the path to look at how ARA does it). Then, we will work on installing pueoSim and testing its current viability.
Bryan
Upon checking the existing plotting scripts used for previous GENETIS work, it appears that they can be used for PUEO with minimal changes. In order to test the plotting scripts, sample output data from the PUEO loop is needed, or at least test data that mimics the form of the output for the PUEO loop. After more progress is made with installing an MC package and the PUEO loop can be run to produce test outputs, the plotting scripts can be tested and implemented in the bash script. |
| Attachment 1: ANITA_Antenna_Project.xmacro
|
App.getActiveProject().getGeometryAssembly().clear();
var freq = [83.33, 100.00, 116.67, 133.33, 150.00, 166.67, 183.34, 200.00, 216.67, 233.34, 250.00, 266.67, 283.34, 300.00, 316.67, 333.34, 350.00, 366.67, 383.34, 400.01, 416.67, 433.34, 450.01, 466.67, 483.34, 500.01, 516.68, 533.34, 550.01, 566.68, 583.34, 600.01, 616.68, 633.34, 650.01, 666.68, 683.35, 700.01, 716.68, 733.35, 750.01, 766.68, 783.35, 800.01, 816.68, 833.35, 850.02, 866.68, 883.35, 900.02, 916.68, 933.35, 950.02, 966.68, 983.35, 1000.00, 1016.70, 1033.40, 1050.00, 1066.70]
CreatePEC();
var units = " cm";
num_ridges = 4; // either 2 or 4
// Make the walls and a ridge
build_walls(10,1,30);
// Note that to avoid overlap, we need x0 >= y0
x0=0.04001; // previously 0.04
y0=0.04; // previously 0.04
build_ridges(x0, y0, 0.0, 0.1, 0.06, 0.3, 0.26, 0.1, 0.1, 1);
CreateAntennaSource();
CreateGrid();
CreateSensors();
CreateAntennaSimulationData();
QueueSimulation();
// Try making copies of the ridge
var new_ridges = new EllipticalPattern();
Output.println(new_ridges.getInstances());
new_ridges.setInstances(7);
//new_ridges.clone();
//Output.println(new_ridges);
// Makes the outer walls of the horn antenna
// S is the side length of the bottom of the wall
// a is the coefficient for the linear function the walls extrude according to
function build_walls(S,m,H)
{
// Make the edges to define the square
var edge1 = Line( new Cartesian3D(-S + units,-S + units, 0), new Cartesian3D(-S + units, S + units, 0));
var edge2 = Line( new Cartesian3D(-S + units, S + units, 0), new Cartesian3D(S + units, S + units, 0));
var edge3 = Line( new Cartesian3D(S + units,S + units, 0), new Cartesian3D(S + units, -S + units, 0));
var edge4 = Line( new Cartesian3D(S + units,-S + units, 0), new Cartesian3D(-S + units, -S + units, 0));
// Declare sketches to be made from the edges
var wallSegment = new Sketch();
var bottomSegment = new Sketch();
wallSegment.addEdge(edge1);
wallSegment.addEdge(edge2);
wallSegment.addEdge(edge3);
wallSegment.addEdge(edge4);
bottomSegment.addEdge(edge1);
bottomSegment.addEdge(edge2);
bottomSegment.addEdge(edge3);
bottomSegment.addEdge(edge4);
// Let's start by making the bottom
var bottomCover = new Cover(bottomSegment);
var bottomRecipe = new Recipe();
bottomRecipe.append( bottomCover );
var bottomModel = new Model();
bottomModel.setRecipe( bottomRecipe );
// Add the surface
//var bottom = App.getActiveProject().getGeometryAssembly().append(bottomModel);
//bottom.name = "Bottom square";
// Now we need to extrude the edges to get height
var walls = new Extrude( wallSegment, H + units); // Makes an Extrude
var wallOptions = walls.getOptions(); // Gives the possible options for
// We will use the draft law option to extrude linearly
wallOptions.draftOption = SweepOptions.DraftLaw; // allows for draftlaw
wallOptions.draftLaw = "("+m+"*x)"; // Set the expression for the extrude
wallOptions.draftOption = 4; // 4 indicates we use draftlaw
//Walter - Change the gap type to Extended to get the desired shape
wallOptions.gapType = SweepOptions.Extended; // I actually don't like this when we have x^2, but it doesn't do much for just x
//Walter - Create a shell instead of a solid part
wallOptions.createSolid = false; // This way the shape isn't filled in
walls.setOptions ( wallOptions ); // Sets the settings we assigned above
// Make a recipe for a model
var wallRecipe = new Recipe();
wallRecipe.append(walls);
var wallModel = new Model();
wallModel.setRecipe(wallRecipe);
wallModel.name = "Outer Walls";
wallModel.getCoordinateSystem().translate(new Cartesian3D(0,0,0)); // Makes the model start at the origin
// Set the material for these parts
var wallProject = App.getActiveProject().getGeometryAssembly().append(wallModel); // Adds the model to the project
var pecMaterial = App.getActiveProject().getMaterialList().getMaterial( "PEC" ); // Makes the material available
App.getActiveProject().setMaterial( wallProject, pecMaterial ); // Sets the material
//App.getActiveProject().setMaterial( bottom, pecMaterial ); // Sets the material
}
// A function to build the inner ridges
// Here are the arguments, which are primarily used when making the LawEdges
// Bottom x distance from center
// Bottom y distance from center
// Top x distance from center
// Top y distance from center
// Full x
// Full y
// Full height
function build_ridges(x_0, y_0, z_0, x_f, y_f, z_f, tau, beta, S, m)
{
// build_ridges(0.04, 0.04, 0.0, 0.1, 0.06, 0.3, 0.26, 0.1, 0.1, 1);
// Logarithmic slopes
//var Log1 = new LawEdge( "0.04 + u", "0.04 + 0.02/0.26*u", "1/10*ln((exp(3)-1.0)/0.26*u+1.0)", 0, 0.26); // alpha = z_max/beta
//var Log2 = new LawEdge( "0.04 + u", "-0.04 - 0.02/0.26*u", "1/10*ln((exp(3)-1.0)/0.26*u+1.0)", 0, 0.26);
var Log1 = new LawEdge( ""+x_0+" + ("+z_f+"-"+x_0+")/"+tau+"*u", ""+y_0+" + ("+y_f+"-"+y_0+")/"+tau+"*u", ""+beta+"*ln((exp("+z_f+"/"+beta+")-1.0)/"+tau+"*u+1.0)", 0, tau); // alpha = z_max/beta
var Log2 = new LawEdge( ""+x_0+" + ("+z_f+"-"+x_0+")/"+tau+"*u", "-"+y_0+" - ("+y_f+"-"+y_0+")/"+tau+"*u", ""+beta+"*ln((exp("+z_f+"/"+beta+")-1.0)/"+tau+"*u+1.0)", 0, tau);
// Inner straight slopes
var IS1 = new LawEdge( ""+x_0+" + ("+z_f+"-"+x_0+")/"+tau+"*u", ""+y_0+" + ("+y_f+"-"+y_0+")/"+tau+"*u", "("+z_f+"-"+z_0+")/"+tau+"*u", 0, tau); // a_0 + at, b_0 + bt, c_0 + ct
var IS2 = new LawEdge( ""+x_0+" + ("+z_f+"-"+x_0+")/"+tau+"*u", "-"+y_0+" - ("+y_f+"-"+y_0+")/"+tau+"*u", "("+z_f+"-"+z_0+")/"+tau+"*u", 0, tau);
// Bottom line
var BL1 = new LawEdge(""+x_0+" + ("+x_f+"-"+x_0+")/"+tau+"*u", ""+y_0+"", ""+z_0+"", 0, tau);
var BL2 = new LawEdge(""+x_0+" + ("+x_f+"-"+x_0+")/"+tau+"*u", "-"+y_0+"", ""+z_0+"", 0, tau);
// Top line
var TL1 = new LawEdge(""+z_f+" + "+x_f+"/"+tau+"*u", ""+y_f+"", ""+z_f+"", 0, tau);
var TL2 = new LawEdge(""+z_f+" + "+x_f+"/"+tau+"*u", "-"+y_f+"", ""+z_f+"", 0, tau);
// Outer Straight slopes
var OS1 = new LawEdge( ""+x_f+" + "+z_f+"/"+tau+"*u", ""+y_0+" + ("+y_f+" - "+y_0+")/"+tau+"*u", ""+z_f+"/"+tau+"*u", 0, tau);
var OS2 = new LawEdge( ""+x_f+" + "+z_f+"/"+tau+"*u", "-"+y_0+" - ("+y_f+" - "+y_0+")/"+tau+"*u", ""+z_f+"/"+tau+"*u", 0, tau);
// Inner top line
var ITL = new LawEdge( ""+z_f+"", "-"+y_f+" + 2*"+y_f+"/"+tau+"*u", ""+z_f+"", 0, tau);
// Outer top line
var OTL = new LawEdge( ""+x_f+" + "+z_f+"", "-"+y_f+" + 2*"+y_f+"/"+tau+"*u", ""+z_f+"", 0, tau);
// Inner bottom line
var IBL = new LawEdge( ""+x_0+"", "-"+y_0+" + 2*"+y_0+"/"+tau+"*u", ""+z_0+"", 0, tau);
// Outer bottom line
var OBL = new LawEdge( ""+x_f+"", "-"+y_0+" + 2*"+y_0+"/"+tau+"*u", ""+z_0+"", 0, tau);
// Make the sketches
var straightEdge1 = new Sketch(); // All straight edges (IS1, BL1, TL1, OS1)
var straightEdge2 = new Sketch(); // All straight edges (IS2, BL2, TL2, OS2)
var curvedLog1 = new Sketch(); // Logarithmic edge (IS1 and Log1)
var curvedLog2 = new Sketch(); // Logarithmic edge (IS2 and Log2)
var topRectangle = new Sketch(); // Top rectangle
var bottomRectangle = new Sketch(); // Bottom rectangle
// Add the edges to the sketches
straightEdge1.addEdges( [IS1, BL1, TL1, OS1] ); // Inner straight slope
curvedLog1.addEdges( [IS1, Log1] ); // Right logarithm part
straightEdge2.addEdges( [IS2, BL2, TL2, OS2] ); // Inner straight slope
curvedLog2.addEdges( [IS2, Log2] ); // Left logarithm part
topRectangle.addEdges( [ITL, OTL, TL1, TL2] ); // Top rectangle
bottomRectangle.addEdges( [IBL, OBL, BL1, BL2] ); // Bottom Rectangle
//WALTER - The Elliptical pattern is added as a recipe to the parts
//In this case the location of the center and direction of the normal are simple, but for more complex scenarios, may need to use mroe functionality to find them.
var ePattern = new EllipticalPattern();
ePattern.setCenter(new CoordinateSystemPosition(0,0,0));
ePattern.setNormal(new CoordinateSystemDirection(0,0,1));
ePattern.setInstances(num_ridges);
ePattern.setRotated(true);
var cov = new Array();
cov.push(new Cover(straightEdge1));
cov.push(new Cover(straightEdge2));
cov.push(new Cover(curvedLog1));
cov.push(new Cover(curvedLog2));
cov.push(new Cover(topRectangle));
cov.push(new Cover(bottomRectangle));
var pecMaterial = App.getActiveProject().getMaterialList().getMaterial( "PEC" );
//WALTER - We can loop over all our parts and add them to the project as follows. You can use similar concepts above.
models = new Assembly();
for(var w = 0; w < cov.length; w++)
{
var r = new Recipe();
r.append(cov[w]);
r.append(ePattern);
var m = new Model();
m.setRecipe(r);
m.name = "Test Surface " + (w+1);
//WALTER - Seperate array for the models, though we could just get them from the GemoetryAssembly again
models.append(m);
App.getActiveProject().setMaterial( m, pecMaterial );
}
// Work on the loft
var vertex_position1 = curvedLog1.getPosition(curvedLog1.getVertexIds()[0]);
var vertex_position2 = curvedLog2.getPosition(curvedLog2.getVertexIds()[0]);
var loft = new Loft(models.at(2).pickFace(new Cartesian3D (0, 0, 0), vertex_position1, 0.5), "0.0", models.at(3).pickFace(new Cartesian3D(0,0,0), vertex_position2, 0.5), "0.0");
loft.setPart1(models.at(2));
loft.setPart2(models.at(3));
var r12 = new Recipe();
r12.append( loft );
r12.append(ePattern);
var m12 = new Model();
m12.setRecipe( r12 );
m12.name = "Loft 1";
models.append(m12);
//WALTER - append the assembly to the project, then loop over it to assign the material
var assembly = App.getActiveProject().getGeometryAssembly().append(models);
for(x = 0; x < assembly.size(); x++)
{
Output.println(assembly.at(x));
App.getActiveProject().setMaterial( assembly.at(x), pecMaterial );
}
}
// CreatPEC Function
function CreatePEC() //borrowed from XF demo
{
//Make the material. We will use PEC, or Perfect Electrical Conductor:
var pec = new Material();
pec.name = "PEC";
var pecProperties = new PEC(); // This is the electric properties that defines PEC
var pecMagneticFreespace = new MagneticFreespace(); // We could make a material that acts as PEC and PMC, but in this case we just care about electrical components.
var pecPhysicalMaterial = new PhysicalMaterial();
pecPhysicalMaterial.setElectricProperties( pecProperties );
pecPhysicalMaterial.setMagneticProperties( pecMagneticFreespace );
pec.setDetails( pecPhysicalMaterial );
// PEC is historically a "white" material, so we can easily change its appearance:
var pecBodyAppearance = pec.getAppearance();
var pecFaceAppearance = pecBodyAppearance.getFaceAppearance(); // The "face" appearance is the color/style associated with the surface of geometry objects
pecFaceAppearance.setColor( new Color( 255, 255, 255, 255 ) ); // Set the surface color to white. (255 is the maximum intensity, these are in order R,G,B,A).
// Check for an existing material
if( null != App.getActiveProject().getMaterialList().getMaterial( pec.name ) )
{
App.getActiveProject().getMaterialList().removeMaterial( pec.name );
}
App.getActiveProject().getMaterialList().addMaterial( pec );
}
function CreateAntennaSource()
{
// Here we will create our waveform, create our circuit component definition for the feed, and create
// a CircuitComponent that will attach those to our current geometry.
var waveformList = App.getActiveProject().getWaveformList();
// clear the waveform list
waveformList.clear();
// Create a gaussian derivative input wave
var waveform = new Waveform();
var GDer = new GaussianDerivativeWaveformShape ();
GDer.pulseWidth = 2e-9;
waveform.setWaveformShape( GDer );
waveform.name ="Gaussian Derivative";
var waveformInList = waveformList.addWaveform( waveform );
// Now to create the circuit component definition:
var componentDefinitionList = App.getActiveProject().getCircuitComponentDefinitionList();
// clear the list
componentDefinitionList.clear();
// Create our Feed
var feed1 = new Feed();
var feed2 = new Feed();
feed1.feedType = Feed.Voltage; // Set its type enumeration to be Voltage.
//feed2.feedType = Feed.Voltage; // Set its type enumeration to be Voltage.
// Define a 50-ohm resistance for this feed
var rlc = new RLCSpecification();
rlc.setResistance( "50 ohm" );
rlc.setCapacitance( "0" );
rlc.setInductance( "0" );
feed1.setImpedanceSpecification( rlc );
feed1.setWaveform( waveformInList ); // Make sure to use the reference that was returned by the list, or query the list directly
feed1.name = "50-Ohm Voltage Source";
var feedInList = componentDefinitionList.addCircuitComponentDefinition( feed1 );
feed2.setImpedanceSpecification( rlc );
feed2.setWaveform( waveformInList ); // Make sure to use the reference that was returned by the list, or query the list directly
feed2.name = "50-Ohm Voltage Source 2";
var feedInList = componentDefinitionList.addCircuitComponentDefinition( feed2 );
// Now create a circuit component that will be the feed point for our simulation
var componentList = App.getActiveProject().getCircuitComponentList();
componentList.clear();
var component1 = new CircuitComponent();
var component2 = new CircuitComponent();
component1.name = "Source";
component2.name = "Source";
component1.setAsPort( true );
component2.setAsPort( true );
// Define the endpoints of this feed - these are defined in world position, but you can also attach them to edges, faces, etc.
var coordinate1 = new CoordinateSystemPosition( -x0, 0, 0);
var coordinate2 = new CoordinateSystemPosition( x0, 0, 0);
var coordinate3 = new CoordinateSystemPosition( 0, -x0, 0);
var coordinate4 = new CoordinateSystemPosition( 0, x0, 0);
component1.setCircuitComponentDefinition( feed1 );
... 84 more lines ...
|
| Attachment 2: ANITA_Horn.png
|  |
| Attachment 3: ANITA_Gain_Pattern_Both_Sources.png
|  |
|
|
206
|
Tue Mar 21 17:58:21 2023 |
Alex M | GENETIS Hackathon Day 2 | Today was day two of the GENETIS hackathon. See the previous entry for details on day one.
Alex
I continued working on the XF scripting for the PUEO horn antenna. Amy showed me an actual horn antenna from ANITA in Lisa's office so I could get the dimensions and see how the loads (power sources in XF) were offset. Offsetting the power sources led to fixing the asyemmtry problem from yesterday. I tested offsetting the loads by various heights and found that they all give the same gain patterns except for when they overlap, proving that they were interfering with each other when they crossed.
There is still, however, an asymmetry between the x and y axes (but the gain patterns are now symmetric across either of them). This is more reasonable, though I'm not positive that it should be this way. I attached an image of the gain pattern to show this asymmetry. Note that it is still at 83 MHz, which is well outside the PUEO bandwidth, but higher frequency gain patterns show the same thing (but they have more nodes so they're harder to look at). I attached images from the x-axis, y-axis, and above of the gain pattern. One way to check this will be to compare to the data stored in PUEOsim/icemc and see if they demonstrate similar asymmetries.
My next step is to test the constraints we've decided on using the script. I'll try out a few different values of the parameters and then if everything is working I'll use the GA Ryan and Dylan wrote to generate many individuals and have XF make the models for them. We don't necessarily need to see the simulation outputs from those XF runs, we just need to see if we run into error. Beyond that, we need to figure out how to extract the proper gain data from XF to create the same format that PUEOsim and icemc use.
Amy also mentioned that we should add the opening angle of the horn antenna as a gene. This may be a little tricky but should be doable. Once we are set with the current XF script and changing the data formatting to match what PUEOsim and icemc need, I'll work on adding that as a gene.
Dylan and Jacob
We tried to get IceMC running and able to read in gain files - we failed. Something was wrong with my make files and Jacob’s c++ compiler, so neither of us got a working version of IceMC. We then switched gears to focus on pueoSim. I created a branch on the nicemc github to output a veff.txt in the format of IceMC, so we can reuse the already-made code. Jacob and I also have been trying to install pueoSim, but we’ve been running into many errors and issues from the “C++ Gods”. For the next steps, I will finish the veffective branch and create a pull request. Then, I will work on a branch to make it so pueoSim can read in a variable path to the gain files.
Ryan
Tuesday: Created a new branch on the PEUO repository, version0.0, and placed the repository in the same location as the Ara one for familiarity. I also added an alias to this directory onto the genstudents channel if people would like to add the path to their .bashrc's. I then went through the the Evolutionary_Loop directory and cleaned up any residual Ara based files that were not needed to run this loop. This will make navigating and troubleshooting easier as we finish building. This branch was then commited and pushed to the github and submitted a pull request. |
| Attachment 1: ANITA_Gain_X.png
|  |
| Attachment 2: ANITA_Gain_Y.png
|  |
| Attachment 3: ANITA_Gain_Z.png
|  |
| Attachment 4: Top_Down_ANITA.png
|  |
|
|
207
|
Mon Mar 27 13:10:02 2023 |
Alex M | GENETIS Hackathon Summary and Next Steps | This entry will serve to summarize what tasks we've completed and still need to complete after last week's GENETIS hackathon.
Alex
My focus was on the XF scripting for making the PUEO antenna. Before last week, we had a script which made the geometry of a PUEO-like antenna. The xmacro script has been modified in the following ways:
- Now includes power sources connecting the ridges that are opposite each other.
- Generalized to use variables without hardcoding.
- Reads in data from the output files of the PUEO GA.
- Loops over all read in antennas to set up all of the simulations at once.
At this point, the script for setting up the simulations of the PUEO loop is just about ready for use. The only change to be made is to the frequency list. The script for printing out the gain data is also ready, though it only prints out the gain in theta and phi, not the cross polarization.
Here are some outstanding points that need to be hammered out, though they impede the quality and accuracy of a run rather than the actual functioning of the loop.
- The shape of the ridges in the generated antennas from the GA are considerably different from the PUEO antenna.
- This is likely something that can be fixed by adjusting the constraints--the subspace of the parameter space that leads to PUEO-like ridges may be very small as-is.
- You can see an example of an antenna from the GA attached (viewed from slightly below). It looks dramatically different. This seems to be due to constraints on the height and width being too small, but the ridges are also clearly misshapen.
- The curve on the ridges looks like it needs some work.
- For very PUEO-like antennas, the slopes look reasonable, but they do flare in or out slightly. This is more dramatic for ridges that deviate from PUEO's significantly.
- My best guess is that the parametric form of the curves is placing the curves in a plane that is different from the rest of the ridge. This should be fixable by somehow constraining the curve to a given plane.
- The simulation still only outputs polarization data for theta and phi, not the cross polarization.
- It looks like XF naturally gives us the theta and phi polarization. It's not clear how to get the cross polarization gain (which we think means the gain when the signal is at 45 degrees).
- One idea is to redo the simulation but with the antenna rotated 45 degrees in the azimuth. But I'm not certain that that iwll work.
- Amy indicated that the correct way to do this is by simulating the antenna with just one power source at a time.
- Leaving the VPol source would produce the VV and VH data and leaving the HPol would produce the HH and HV data (HV and VH could be flipped!).
- Currently, the antennas have a fixed opening angle. We'd like to add this as a parameter, though at the moment it might be ok to forego that.
- We need to make sure that the power sources aren't too close together (fixed!).
To do for this week:
1. Modify the script to make two simulations for each antenna, each with only one power source.
2. Adjust the constriants on the parameters to fix the curvature.
3. When we begin a run, we will want to just evolve the height and the inner side length (these determine both the inner side length and the outer side length).
Dylan and Jacob
Dylan and Jacob focused on getting PUEOsim/icemc working, which will be the simulation software needed for the PUEO loop. Here's a summary from Dylan:
- Plotting and bash scripts should be mostly good to go.
- Currently have 4/5 of the PUEO prerequisites for pueoBuilder, and the GENETIS-specific code is ready to implement and test when it's built. I’m trying to build the correct root version one more time before today’s meeting, and if it fails again I’m going to ask Will.
- The main thing left is to get the correct version of root installed, which while annoying, shouldn't take too long
To do for this week:
1. Once PUEOsim is working, run it with the usual settings to get the default performance. It will need to be submitted as a job array (ask Alex for help with this if you need; ask Will for advice on how many neutrinos to run).
|
| Attachment 1: Weird_PUEO_Model.png
|  |
|
|
208
|
Wed Mar 29 18:36:29 2023 |
Alex M | GENETIS Working Meeting Update | This is an entry for the usual Wednesday working meeting GENETIS holds. We are largely carrying on from last week's hackathon hammering out the remaining pieces that need to be fixed. See the previous ELOG post for a list of those.
Alex
Amy pointed out on the Monday call that the proper way to simulate the ANITA antenas is to use one source at a time. I modified the script I had so that it makes two simulations per antenna. The first one will use the power source connected to the "VPol" ridges and the second one uses the one connected to the "HPol" ridges. After checking this, it looks like the asymmetry I had pointed out before fell away. In other words, I think XF only wanted to use a single power source anyway. So now we should be able to produce the VV, HH, VH, and HV data that icemc and PUEOsim need.
Ryan and I also worked a bit on the slopes of the ridges. We experimented with the parameter that affects the curvature, which seems to be able to be too large. But many of the designs still look to have almost no slope and many still caved inward rather than sloping outward. We're still working on figuring out what causes that, but I think it means we need another constraint on distance of the top of the inner ridges from the center.
We also tried figuring out why the sides of the curved part of the ridges don't stay in the same plane as the straight part of the ridges. I'm confident that they do stay in a single plane (I attached a Mathematica notebook that shows as much by finding that the torsion of the curve is zero; for some reason I couldn't print it to a PDF). We think that we should be able to rotate the curve into the same plane as the straight part of the ridge, but I haven't figured out how yet.
Nick and I continued working on the HPol antenna. We want to check if there are any other things in Steph's example XF file that are significant to the results of the simulation (versus just being there as a representation of the model). It looks like there are, and Nick is working to figure out what they are by deleting them (in a copy) and generating simulation results for them to compare to the original. Otherwise, the most significant parts (the copper plates) are now being made in a script and just need to be connected to one another.
Dylan
I tried to build root from source again and ran into an error 3 hours into the build. I messaged Will and asked if he knew anything about the error. I then reran the build with Will's suggested change and ran into the same error 3 hours later. I did, however, manage to build pueo by sourcing the installation of root in Will's shared pueo directory. I'm now testing getting a txt output file from the simulation as it turns out my initial solution didn't work.
Update:
I got a working version of root installed. Also, I was able to modify pueoSim to output a veff.txt file. Now, I need to modify where it reads in the gain files, and then modify the icemc specific bash scripts to work for pueosim. |
| Attachment 1: Modeling_ANITA_Ridges.nb
|
(* Content-type: application/vnd.wolfram.mathematica *)
(*** Wolfram Notebook File ***)
(* http://www.wolfram.com/nb *)
(* CreatedBy='Mathematica 12.0' *)
(*CacheID: 234*)
(* Internal cache information:
NotebookFileLineBreakTest
NotebookFileLineBreakTest
NotebookDataPosition[ 158, 7]
NotebookDataLength[ 141335, 3108]
NotebookOptionsPosition[ 137462, 3039]
NotebookOutlinePosition[ 137824, 3055]
CellTagsIndexPosition[ 137781, 3052]
WindowFrame->Normal*)
(* Beginning of Notebook Content *)
Notebook[{
Cell[BoxData[""], "Input",
CellChangeTimes->{{3.889104537246646*^9, 3.8891045516248693`*^9}, {
3.88910472825602*^9, 3.889104729415251*^9},
3.889118788593347*^9},ExpressionUUID->"f2d7bf67-519b-4366-9a10-\
f19376de6bb8"],
Cell["<\
Here, I will use an example ridge that I have made and tested in XF to \
demonstrate how the curved part of the ridges slope in.
Here is a figure that represents one of these ridges. We are viewing it \
directly at the edge of the ridge, so the blue line actually represents the \
side. The purple curve should lie directly aligned with the blue line but \
doesn[CloseCurlyQuote]t. The same goes for the green line and orange/red \
lines (which do lie in the same plane, but that plane isn[CloseCurlyQuote]t \
aligned with the other side) below, which is the other side of the ridge.\
\>", "Text",
CellChangeTimes->{{3.889118836397954*^9,
3.889119017191614*^9}},ExpressionUUID->"0859e4b4-741b-4eea-b2b6-\
e446b9af7816"],
Cell[BoxData[
RowBox[{
RowBox[{"x0", "=", "4"}], ";", " ",
RowBox[{"y0", "=", "4"}], ";",
RowBox[{"z0", "=", "0"}], ";", " ",
RowBox[{"yf", "=", "6"}], ";", " ",
RowBox[{"H", "=", "30"}], ";", " ",
RowBox[{"zf", "=", "30"}], ";", " ",
RowBox[{"xf", "=", "zf"}], ";", " ",
RowBox[{"[Beta]", "=", "2"}], ";",
RowBox[{"[Tau]", "=", "0.26"}], ";"}]], "Input",
CellChangeTimes->{{3.8891047313587914`*^9, 3.889104784350019*^9}, {
3.889105008478373*^9, 3.889105011515078*^9}, {3.889106004732277*^9,
3.88910602661027*^9}, {3.889112979624475*^9, 3.889112979661337*^9}, {
3.8891130240801353`*^9, 3.889113037799301*^9}},
CellLabel->
"In[433]:=",ExpressionUUID->"fb3dee39-fae9-47d5-bb54-52d21df6980e"],
Cell[CellGroupData[{
Cell[BoxData[
RowBox[{"ParametricPlot3D", "[",
RowBox[{
RowBox[{"{", "[IndentingNewLine]",
RowBox[{
RowBox[{"{",
RowBox[{
RowBox[{"x0", "+",
RowBox[{
RowBox[{
RowBox[{"(",
RowBox[{"zf", "-", "x0"}], ")"}], "/", "[Tau]"}], "*", "t"}]}],
",",
RowBox[{"y0", "+",
RowBox[{
RowBox[{
RowBox[{"(",
RowBox[{"yf", "-", "y0"}], ")"}], "/", "[Tau]"}], "*", "t"}]}],
",",
RowBox[{
RowBox[{
RowBox[{"(",
RowBox[{"zf", "-", "z0"}], ")"}], "/", "[Tau]"}], "*", "t"}]}],
"}"}], ",", "[IndentingNewLine]",
RowBox[{"{",
RowBox[{
RowBox[{"x0", "+",
RowBox[{
RowBox[{
RowBox[{"(",
RowBox[{"zf", "-", "x0"}], ")"}], "/", "[Tau]"}], "*", "t"}]}],
",",
RowBox[{
RowBox[{"-", "y0"}], "-",
RowBox[{
RowBox[{
RowBox[{"(",
RowBox[{"yf", "-", "y0"}], ")"}], "/", "[Tau]"}], "*", "t"}]}],
",",
RowBox[{
RowBox[{
RowBox[{"(",
RowBox[{"zf", "-", "z0"}], ")"}], "/", "[Tau]"}], "*", "t"}]}],
"}"}], ",", "[IndentingNewLine]",
RowBox[{"{",
RowBox[{
RowBox[{"x0", "+",
RowBox[{
RowBox[{
RowBox[{"(",
RowBox[{"xf", "-", "x0"}], ")"}], "/", "[Tau]"}], "*", "t"}]}],
",", "y0", ",", "z0"}], "}"}], ",", "[IndentingNewLine]",
RowBox[{"{",
RowBox[{
RowBox[{"x0", "+",
RowBox[{
RowBox[{
RowBox[{"(",
RowBox[{"xf", "-", "x0"}], ")"}], "/", "[Tau]"}], "*", "t"}]}],
",",
RowBox[{"-", "y0"}], ",", "z0"}], "}"}], ",", "[IndentingNewLine]",
RowBox[{"{",
RowBox[{
RowBox[{"xf", "+",
RowBox[{
RowBox[{"xf", "/", "[Tau]"}], "*", "t"}]}], ",", "yf", ",", "zf"}],
"}"}], ",", "[IndentingNewLine]",
RowBox[{"{",
RowBox[{
RowBox[{"xf", "+",
RowBox[{
RowBox[{"xf", "/", "[Tau]"}], "*", "t"}]}], ",",
RowBox[{"-", "yf"}], ",", "zf"}], "}"}], ",", "[IndentingNewLine]",
RowBox[{"{",
RowBox[{
RowBox[{"xf", "+",
RowBox[{
RowBox[{"zf", "/", "[Tau]"}], "*", "t"}]}], ",",
RowBox[{"y0", "+",
RowBox[{
RowBox[{
RowBox[{"(",
RowBox[{"yf", "-", "y0"}], ")"}], "/", "[Tau]"}], "*", "t"}]}],
",",
RowBox[{
RowBox[{"zf", "/", "[Tau]"}], "*", "t"}]}], "}"}], ",",
"[IndentingNewLine]",
RowBox[{"{",
RowBox[{
RowBox[{"xf", "+",
RowBox[{
RowBox[{"zf", "/", "[Tau]"}], "*", "t"}]}], ",",
RowBox[{
RowBox[{"-", "y0"}], "-",
RowBox[{
RowBox[{
RowBox[{"(",
RowBox[{"yf", "-", "y0"}], ")"}], "/", "[Tau]"}], "*", "t"}]}],
",",
RowBox[{
RowBox[{"zf", "/", "[Tau]"}], "*", "t"}]}], "}"}], ",",
"[IndentingNewLine]",
RowBox[{"{",
RowBox[{
RowBox[{"x0", "+",
RowBox[{
RowBox[{
RowBox[{"(",
RowBox[{"zf", "-", "x0"}], ")"}], "/", "[Tau]"}], "*", "t"}]}],
",",
RowBox[{"y0", "+",
RowBox[{
RowBox[{
RowBox[{"(",
RowBox[{"yf", "-", "y0"}], ")"}], "/", "[Tau]"}], "*", "t"}]}],
",",
RowBox[{"[Beta]", "*",
RowBox[{"Log", "[",
RowBox[{
RowBox[{
RowBox[{"t", "/", "[Tau]"}], "*",
RowBox[{"(",
RowBox[{
RowBox[{"Exp", "[",
RowBox[{"zf", "/", "[Beta]"}], "]"}], "-", "1"}], ")"}]}], "+",
"1"}], "]"}]}]}], "}"}], ",", "[IndentingNewLine]",
RowBox[{"{",
RowBox[{
RowBox[{"x0", "+",
RowBox[{
RowBox[{
RowBox[{"(",
RowBox[{"zf", "-", "x0"}], ")"}], "/", "[Tau]"}], "*", "t"}]}],
",",
RowBox[{
RowBox[{"-", "y0"}], "-",
RowBox[{
RowBox[{
RowBox[{"(",
RowBox[{"yf", "-", "y0"}], ")"}], "/", "[Tau]"}], "*", "t"}]}],
",",
RowBox[{"[Beta]", "*",
RowBox[{"Log", "[",
RowBox[{
RowBox[{
RowBox[{"t", "/", "[Tau]"}], "*",
RowBox[{"(",
RowBox[{
RowBox[{"Exp", "[",
RowBox[{"zf", "/", "[Beta]"}], "]"}], "-", "1"}], ")"}]}], "+",
"1"}], "]"}]}]}], "}"}]}], "[IndentingNewLine]", "}"}], ",",
RowBox[{"{",
RowBox[{"t", ",", "0", ",", "[Tau]"}], "}"}]}], "]"}]], "Input",
CellChangeTimes->{{3.889104789299713*^9, 3.889105080982005*^9}, {
3.88910513362922*^9, 3.889105134787335*^9}, {3.889105176753415*^9,
3.889105183526766*^9}, {3.889105234070648*^9, 3.8891053106544733`*^9}, {
3.8891053894877863`*^9, 3.889105467143161*^9}, {3.889105814148295*^9,
3.889105946276293*^9}, 3.88911016079349*^9, 3.889111844551866*^9},
CellLabel->
"In[434]:=",ExpressionUUID->"a2747aaf-59c9-498b-a918-186b6556d2ae"],
Cell[BoxData[
Graphics3DBox[{{{}, {},
TagBox[
{RGBColor[0.368417, 0.506779, 0.709798], AbsoluteThickness[2],
Line3DBox[CompressedData["
1:eJwVjHk41Isexh1ahha/2fyQiIZkG2Mf/JrXcitCi4RzSUI8t1G3EUqbJCod
RyqpQ9f2KGSo64QkmpTUTWWP0mI5kVD2/c75432+z/t5Pu9Xc+/BHUGyMjIy
rtLISePx7o+1MjIEVK0qZf++4511NZyEnA0FF57G6NEINETP1GdIedNN5aN2
bTGCX2yHPu8kCFyo4/9h9wsBsF/vVW5LFohv2mfkrSEw/et90zOyBCK25bfK
tWUJlgT2qbnbEXh3oihwyWIC9EEyear1nqB00EIpN4ZA6pPMZ8sVCHx86HZw
tFUiUFnUQHNZTIfS1rgLKiwCGzn9H360Ngg+GNEGrykwQN+3lWGqS2Cq1fLq
cOsXgc6zO10cOxaCzj6S1LoTkDjcynmbNSKoD35xUmeHEmaXilYfPU5g1cfy
3r0Gc4KJNxkptV7KOC/apLE7hwBT6Je/1EEOn44VvfNNUMXh+qnHOa8JJPE2
Vrh50KDHs5SEpKoh87fhlbRJAq2pxtU/iBUw051oDnmrDv0NNbP/W0tHQs6p
17IqdPiNWJouil6DOy3ll5660UFe6Tp/OZ2JplZjt8RYTRxsGHnTHkFH/E6n
DQ3jbOh9eDrP+I8WkqoU7m7PoiOMn+lXF6MMcTAp25C7FqOK+2x6XtDhODQd
daBLFaMeT5/syePAdXOX8M5POmJst/urWq2GapDiqv7H2lgkogTNqxmwEV8v
OVmlgQNT7KeFtTqYm++oUN3IgHDyR/TzFZrIEZctEnatw84Tnu8eH2JgUp/o
NPTQwvXaUtnpKV1kdo2mp6UxYF1wJyMlZS0eBYW5S+bWg1fYsvxKDQNDDOc9
uyQc1HBe8s+S+lAPuar2fYiBLxf37BIt1cFUyEdRjLoB3OJSW/YqM7FpKNKp
x2IdiPrf7aJsDNFx9QjP2pGJbwG0sJJTuuhNSau3czfC7t+iTP9xkAlHDikb
L1mPge4gsYMXF5yv1R+F15ggXukkFg/poS+vh57BN8Zms26DcQkTq84VbbOw
MMBo9nh4RaUxxF1bOGnfmLimzyeYwYb49Nq8fIOAB4VjzZJwJgsvVO3MRy4Z
wXa5w6aqlzzUyNnK3t3AgrWaJInbwgU3QTz/3s0E1UO932jBLCjKZR32jzFG
supXmcn3JlB9dSBCksyCxmkNW28dHlo6tn6JCjHFv5KVbxdVsrBc2+f+jloe
/vuR/f1GvylmHyyJLe9hgUepFEX6mmBhJM++LNIMA01vZbTpbIR3Mp44y5ii
yzntsWjGDOo7Pq8r5LPxc+Sih1OqKW41PtS4etwcm0oZ4yH+bDhzn91wMjRD
h7DgeQnNAq9WaAbFXWRDMmIzM1FvhlubJ28cSrBASm3YyeoSNkQGJu1vg8zR
ZcYs01exxENRtpXPJzbsBwObvOUtUBZwcT4m3RLap8l0lrwSnDnKriuyLCCs
MeXYa1ghNrLwtgxPCUbRF45ILC2RZJ53Zb7ACvBb4+HmowTjIH6VdrslXPqO
G3lx+RDktxaUxSpB+CgktuSQFY4WqjOLKvlI692fHVushNqMpsAfbD7isgdb
Qp2sMaigZR/boYS52wsT3FI+9N6r1dS9tMaZZLWEDDkSQu0C+Ruu1hBoq8xq
edsgYtnoYXUuiRm9yxb3hq0xUBzmq/LBBgV/KcqXe5KQ5Mx8HjtngyMHZtMj
d9uipcDVMf4UiUDHtbBRt0W4rfv6xn5b+PmHrCnNJ6EdGl9uVG0LeVda58tQ
CnpRtblyjSQ0FIR3XT0pzP0uFLP+TWFvsGZqqZSLHU5EDXtTGGx4c9JXRCF1
57Hz+5tI2JxIdLjsQ6HR67rGUASFJVyusLGZhOdwcXObP4X0QD1/RjSFL10p
vOw2EoktY1MBQgq84y7dXskUrrvue2jfSWI+65R91GkKvxYk9ffcp0DTXNxw
uo9Ep83lxtwCCi6Dow+MyikIVvo9Me8nsT88J81JLO0874TICgoRM2UlfVI+
Lf4zaKCYgnappoF8NYXuZuG17QMklLXaJnjSv0OSe6EGdRSqLzT5aA6R2Epb
rVYp9c60Nw2LOihEjmb/VT1KoqopN7CxWfp3Nf9xxQcK4s9zbYfHSLitLDOM
aKMQsif90qJPFHrqPV/ojpPo2FQ3rizdu/YGmaR0U3DPW1aYNEFi4sG3c7ul
HvlzPKz8OwWj3WGiPdMkjDKNC/v6KSiY/9NRdpjCvi2vAlgzJCrb7SIuSr3Z
yCrWlp8U0qzWeTyXcmeWu4Ar9T7Pxf/5fly6Y3ZYGs+R2Bcf/vbwGIUmDJzV
nqJgJ2O+vlvKx6rjbpCTFJ6d2bbrwAyFI98TVVPnScRMXwt4ME2h9FmJTukc
haL2r8tcFkgomuUZ+Ep7vrzKxMIChd5a+7kFKb8Z+mDs7/5/SZ4y2A==
"]]},
Annotation[#, "Charting`Private`Tag$112685#1"]& ],
TagBox[
{RGBColor[0.880722, 0.611041, 0.142051], AbsoluteThickness[2],
Line3DBox[CompressedData["
1:eJwVjHk81Psexh1UQ4vfbH7IEs1ItjH2YX7Nx3IrQouEc0mWKa/bpNvYSpsk
CseRCjl0bS8lGdV1siXfJpG6qewRkuVEQtmX4c754/njeb/ez6MdcPIAX1ZG
RsZVGjlpPD7+sVVGBgM16xopxtBsb2MdI7FgR3HCyxh9EgbN0UtNOVLeekfl
jF1nDO8X7kT/QQyDhEbOH3a/YAjo7wJUOlN5ojv2OUVbMFj89YnZZVkMRey7
3yHXmcdbGzSi7m6HwcfzpUFr12CIPI6nLnQ85pWPWyoXxmCQ8SK3foMihvqe
up2c7hDzVOWbSS5ryKC8Ny5BlYahnYzRnh8dzbweY9J4uiIFyEf3Usz0MLTQ
YXVrsuMLT7f+wQDDjgb8K8/EDe4YEjvcLfiQN8VrOvb6gu4BZVheJ9Q4cw5D
m/sqhwMMJby59zlpDV4qcE24S+twAYaoAr/76xzk4PPZ0o++iWoQ1rTwvOAd
hlLYO6vdPEigz7YSB2eoQ+5vk5tI8xjqyDBBP7CNYK431xb8QRMMdtQt/28r
GSUWXHwnq0oGvykrM/noLfCgvfL6Szcywm8OXLuRTYXWDhO35FhtONk89b4r
goziDzrtaJ6lg37PyxXKf3QgpVbx0f48Mgrl5Po1xqiA6Bgu21y4FaaVjtoO
vSYjx4nFqJABNZj2ePniSBEDXHcPCB78JKMY7n5/NWsNUOMrbR59zgR5IcFr
06AgW9Htsgu1WhCyQH9Z0qALkpXuarWdFCSY/xH9aqM2FIgq5AUD2+Dgec+P
z09R0LwB1mvkoQO3G8plFxf0IHdgOjsri4Jsih/kpKVthWf8UHexZDuwS9o3
3KyjoAmK85FDYgbUMd5wruAGoBl8S/37BAV9STpySLhOFxaC+4QxmobgFpfR
HqBCRbsmIp2GLLcB1vS7XZStEXTfOs22caSib4Gk0LKLejCcltVk524Mh3+L
MvvHSSpyZOCy8eLtMDbIFzl4sYDxFfUJ0qkIe6ub/HBCH0aKhsg5HBPYbT5o
OCumos1XS/dZWhrCdP5seHWNCYgG9jCyvlFRugEHox4zgs/vLCp38NigeLZN
HE6loddqdhZT142Bu8FhV+0bNtTJcWUf7aAhG3VxCqudBaxE0conN1NAE8Pf
SMdoSEkuL8w/xgRS1b7KzH8yBbW3IRHiVBrSuqTF9dZlQ3v33i9RwWbwr1SV
e6U1NLSB6fPkQAMb/ttH/545agbLVWtjK4doiE2olkb6msLqVJF9RaQ5jLV+
kGGS6Si8l/LCWcYMBpyznguXzEHzQP+2Eg4d/ZxK8nDKMIO7LU+1bp2zgF3l
lNlgfzpyZtVnOhmZQ7eg+FUZyRLebtTmxyXRkXjKdmmuyRzu7p7PPJVoCWkN
oRdQGR0JDU27PvAtYMCcWmGgagVPhfnWPp/pyH48qNVbwRIqApNWYrKtgHkJ
z6YpKCNnhorrxjxLENSZMey1rCE2suSeDFsZGUcnnBZbWUGKRdHNlWJrAL8t
Hm4+ysiEz6lldlmBy8g5Yy8WB3j3O4orYpWR4FlwbNkpazhTokktreFA1vDx
/NiHyqghpzXoB50Dcfnj7SecbGBcUcc+tlsZSe6tzrHKOaD/Sb2u8Y0NXE5V
T8yRw5GAWayQ6WoDPKbqso63LUSsnw7TZOFoSf+G5eNJGxh7GOqr2mMLxX8p
KVR64khcsNQ/c9UWTocsZ0ce5kJ7satj/EUcBTluBVtNLoRz3be3jHLBzz94
... 2817 more lines ...
|
|
|
209
|
Tue Apr 4 13:51:56 2023 |
Alex M | Final To Do List for PUEO Loop | At the main GENETIS meeting yesterday, we collected the last few things that need to be worked out in order to get the PUEO loop in working order. Here's a list
-
Skeletonize the xmacros (Alex) 04/10/23 In progress
-
We need to modify PUEOsim to read in different gain files (Dylan) Changes made 04/10/23 Testing to be done.
-
Currently, PUEOsim reads in files like vv_0, vh_el, etc. It needs to be modified to take in the gainfiles as arguments and read different ones for each individual.
-
Requiers slight modification of the batch job scripts, but these are relatively small
-
Slight modification on the fitness score read in script (Dylan) Changes made 04/10/23 Testing to be done.
-
Fix Ezio's comments on XFintoPUEO.py and modify to read in outputs from two files (Jacob) 04/10/23 in progress, further work this week
-
Since we are running XF twice (once for each power source), we need the conversion script to read in from two files and print out to 8 files (vv_0, vh_el, etc)
|
|
|
213
|
Thu Apr 27 01:36:32 2023 |
Alex M | Results from paper symmetric run | The reviewer asked us to run the loop again but for just symmetric antenna designs. We have completed that run and have results ready. We still need to resimulate the top five individuals, which I'll update this post with later. I attached the violin plot (though it should be fixed to not let the legend overlap the data). See this previous entry for the details of the run: http://radiorm.physics.ohio-state.edu/elog/GENETIS/198 |
| Attachment 1: Violin_Plot.png
|  |
|
|
214
|
Sun Apr 30 03:45:07 2023 |
Alex M | Preliminary PUEO Run | We have the PUEO loop in working order, though there are a few errors in accuracy and efficiency. We started a preliminary run with few individuals and neutrrinos as a large scale test that may still give us some useful data.
For this run, we are only evolving the inner side length (10cm to 25 cm) and height (10 cm to 50 cm). The walls are slanted at 45 degrees, so the outer length is completely defined by those two. The ridges are kept at 6 cm wide and 4 cm from the walls at the base. The curvature is set to 0,1 and the ridges are set to have the same height as the walls.
At the moment, we are using 24 individuals and 300,000 neutrinos. I'll update this ELOG post with more details from the run as they emerge. |
| Attachment 1: PUEO_run_details.txt
|
####### VARIABLES: LINES TO CHECK OVER WHEN STARTING A NEW RUN ###############################################################################################
RunName='2023_04_29_Test_10' ## This is the name of the run. You need to make a unique name each time you run.
TotalGens=100 ## number of generations (after initial) to run through
NPOP=24 ## number of individuals per generation; please keep this value below 99
Seeds=2 ## This is how many AraSim jobs will run for each individual## the number frequencies being iterated over in XF (Currectly only affects the output.xmacro loop)
FREQ=60 ## the number frequencies being iterated over in XF (Currectly only affects the output.xmacro loop)
NNT=1000 ## Number of Neutrinos Thrown in AraSim
exp=18 ## exponent of the energy for the neutrinos in AraSim
ScaleFactor=1.0 ## ScaleFactor used when punishing fitness scores of antennae larger than the drilling holes
GeoFactor=1 ## This is the number by which we are scaling DOWN our antennas. This is passed to many files
num_keys=4 ## how many XF keys we are letting this run use
database_flag=0 ## 0 if not using the database, 1 if using the database
## These next 3 define the symmetry of the cones.
PUEO=1 ## IF 1, we evolve the PUEO quad-ridged horn antenna, if 0, we evolve the Bicone
RADIUS=1 ## If 1, radius is asymmetric. If 0, radius is symmetric
LENGTH=1 ## If 1, length is asymmetric. If 0, length is symmetric
ANGLE=1 ## If 1, angle is asymmetric. If 0, angle is symmetric
CURVED=1 ## If 1, evolve curved sides. If 0, sides are straight
A=1 ## If 1, A is asymmetric
B=1 ## If 1, B is asymmetric
SEPARATION=0 ## If 1, separation evolves. If 0, separation is constant
NSECTIONS=2 ## The number of chromosomes
DEBUG_MODE=0 ## 1 for testing (ex: send specific seeds), 0 for real runs
## These next variables are the values passed to the GA
REPRODUCTION=6 ## Number (not fraction!) of individuals formed through reproduction
CROSSOVER=10 ## Number (not fraction!) of individuals formed through crossover
MUTATION=1 ## Probability of mutation (divided by 100)
SIGMA=5 ## Standard deviation for the mutation operation (divided by 100)
ROULETTE=2 ## Percent of individuals selected through roulette (divided by 10)
TOURNAMENT=2 ## Percent of individuals selected through tournament (divided by 10)
RANK=6 ## Percent of individuals selected through rank (divided by 10)
ELITE=0 ## Elite function on/off (1/0)
|
|
|
215
|
Mon May 1 05:45:02 2023 |
Alex M | Midscale PUEO Run | I've started a run of the PUEO loop to get some data for evolving the antenna width and height. We are running with 24 individuals, each with 400k neutrinos at an energy exponent of 19. Here is the output directory: /fs/ess/PAS1960/HornEvolutionOSC/GENETIS_PUEO/BiconeEvolution/current_antenna_evo_build/XF_Loop/Evolutionary_Loop/Run_Outputs/2023_05_01_Test_5
It's very important to note that the cross-pol data being used still comes from the data already stored in pueosim. This is because our extremely low cross polarizations were causing us to have no effective volumes. There's likely some issue in what values from XF we are choosing as our crosspols. |
| Attachment 1: run_details.txt
|
####### VARIABLES: LINES TO CHECK OVER WHEN STARTING A NEW RUN ###############################################################################################
RunName='2023_05_01_Test_5' ## This is the name of the run. You need to make a unique name each time you run.
TotalGens=10 ## number of generations (after initial) to run through
NPOP=24 ## number of individuals per generation; please keep this value below 99
Seeds=10 ## This is how many AraSim jobs will run for each individual## the number frequencies being iterated over in XF (Currectly only affects the output.xmacro loop)
FREQ=60 ## the number frequencies being iterated over in XF (Currectly only affects the output.xmacro loop)
NNT=40000 ## Number of Neutrinos Thrown in AraSim
exp=19 ## exponent of the energy for the neutrinos in AraSim
ScaleFactor=1.0 ## ScaleFactor used when punishing fitness scores of antennae larger than the drilling holes
GeoFactor=1 ## This is the number by which we are scaling DOWN our antennas. This is passed to many files
num_keys=6 ## how many XF keys we are letting this run use
database_flag=0 ## 0 if not using the database, 1 if using the database
## These next 3 define the symmetry of the cones.
PUEO=1 ## IF 1, we evolve the PUEO quad-ridged horn antenna, if 0, we evolve the Bicone
RADIUS=1 ## If 1, radius is asymmetric. If 0, radius is symmetric
LENGTH=1 ## If 1, length is asymmetric. If 0, length is symmetric
ANGLE=1 ## If 1, angle is asymmetric. If 0, angle is symmetric
CURVED=1 ## If 1, evolve curved sides. If 0, sides are straight
A=1 ## If 1, A is asymmetric
B=1 ## If 1, B is asymmetric
SEPARATION=0 ## If 1, separation evolves. If 0, separation is constant
NSECTIONS=2 ## The number of chromosomes
DEBUG_MODE=0 ## 1 for testing (ex: send specific seeds), 0 for real runs
## These next variables are the values passed to the GA
REPRODUCTION=6 ## Number (not fraction!) of individuals formed through reproduction
CROSSOVER=10 ## Number (not fraction!) of individuals formed through crossover
MUTATION=1 ## Probability of mutation (divided by 100)
SIGMA=5 ## Standard deviation for the mutation operation (divided by 100)
ROULETTE=2 ## Percent of individuals selected through roulette (divided by 10)
TOURNAMENT=2 ## Percent of individuals selected through tournament (divided by 10)
RANK=6 ## Percent of individuals selected through rank (divided by 10)
ELITE=0 ## Elite function on/off (1/0)
|
|
|
216
|
Tue May 9 18:09:35 2023 |
Alex M | 05/08/23 Pueo Run | Here are the run details for the latest PUEO run we've started. There are still some bugs that need to be worked out, which are detailed on the github. Here is the directory where the data is stored: /fs/ess/PAS1960/HornEvolutionOSC/GENETIS_PUEO/BiconeEvolution/current_antenna_evo_build/XF_Loop/Evolutionary_Loop/Run_Outputs/2023_05_08
This run uses 50 individuals per generation with 400k neutrinos per individual at an energy exponent of 19. Only the inner side length and outer sidelength are being evolved (which evolves the height since the opening angle is fixed).
Issues With Part E (Dylan):
The Plots were not automatically created for the first generation. After a quick look through, I found that the fitness score and v effective csv files were being moved before they were copied, so the files didn’t end up in the correct place. Additionally, the errorbars.csv file was not being created, so I made a temporary fix to create a file of 0 error bars to allow for plotting the values while I work on getting the real error values.
Update: I have modified Will’s script for reading the root file outputs, so it can now read them to output a CSV file with the effective volume along with its positive and negative errors. This script does the same and more as the fitnessfunctionPUEO.py, so I will replace it in the loop when there is downtime. Additionally, this script means we don’t need to output a veff.csv file from pueoSim. I will now work on creating a less “janky” version of my pueoSim change for reading in the gain files, so I can get Will to officially add it to pueoSim and we can pull any updates in the future.
Update, Implementing the new script into Part E:
The rootAnalysis.py script is very picky with environment variables. So, first I had to load and then unload a version of python to make sure the default version is loaded. Then, I moved the sourcing of set_plotting_env.sh to later in the script to avoid having an alternate version of root sourced while running (this would cause errors). Then I source the environment for pueosim (path hardcoded, change when loop isn’t running) and loop through the rootAnalysis.py program for each individual in the generation. This will output a ${gen}_fitnessScores.csv and a ${gen}_errorBars.csv in the run directory for plotting script to use. Because it outputs these automatically, I commented out the old methods we used to create these files and removed the temporary error bar fix as well.
Another Update:
We paused the loop. I changed the hardcoded parts, and we pushed the new updates to the github. I will make comments on the changes later today.
Wednesday:
It seems like the loop is still not creating the csv files or plots for generation 1 or 2. Alex gave me the error message. The python script rootAnalysis.py had an issue with the include Geoid.h line. This was caused by sourcing the wrong things while trying to get the script working. I found that I only changed my local pueoSim environment to include the fftw installation to the $PATH and $LD_LIBRARY_PATH variables. So, I changed /fs/ess/PAS1960/buildingPueoSim/set_env.sh as well. Also, I found that the include statements in rootAnalysis.py were missing the PAS1960 portion of the path. After fixing these, and adding a missing ‘/’ to the output file path, I manually ran the rootAnalysis.py program for the 2023_05_08 run, mimicking the portion of the bash script that runs it in Part_E. It outputted the correct files in the correct format. I then ran the FScorePlot script. The median line for the ViolinPlot seemed wrong, and the FScorePlot was too scrunched with a y start of 0; I will need to change these.
Plotting Update (Dylan):
Ok, plots still aren’t being made, and I’m not running the loop, so I don’t have access to the error messages, so I’ll go through everything one by one. For Veff_Plots, this isn’t being made as there are currently no vEffectives.csv. This isn’t a big deal, as it’s just a copy of FScorePlot, but I added the creation of vEffectives.csv to rootAnalysis.py anyway. Next, I noticed that runData.csv, which is required for a couple of the plots was not being made. I looked, and the version of gensData.py had the old values for the skiprows when reading in the fitnessScores and generationDNA files, something that was overlooked when we merged the version I was developing with the version Alex was developing on. I can’t access the directory or the file, I think this is why it was overlooked in the merge. I created a temporary PUEO version in Antenna_Performance_Metric (I’m also fine with it just living here permanently).
Also, the csv files are now in the GenerationData/ directory in the run directory? This affects every plotting script and they will not work without changes. I don’t know why this was changed or if this change is permanent?
Next, ok apparently, VariablePlots isn’t even a file in the loop? We really need to use GitHub better.
I moved my local version of the program into the loop and it ran fine manually.
I am forsaking the Generation_Data directory, so I changed the rainbowPlotter and dataConverter scripts to read in a location to match all the other plotting scripts. They both also ran fine manually.
Note: The rainbowPlotter script should be able to create a gradient from the minimum fitness score to the maximum fitness score. (currently, the range is hardcoded and this can cause basically a mono-color graph.)
FScorePlot should be good
The bash script was inputting 5 variables into colorplots when the pueo version only takes in 4 (this is also something that was already fixed before the merge.) It also requires the vEffective.csv files. After copying over the fitnessScore.csv files to vEffective.csv files, it ran fine. (The vEffective.csv files will be made automatically by rootAnalysis.py in the future) |
| Attachment 1: run_details.txt
|
####### VARIABLES: LINES TO CHECK OVER WHEN STARTING A NEW RUN ###############################################################################################
RunName='2023_05_08' ## This is the name of the run. You need to make a unique name each time you run.
TotalGens=10 ## number of generations (after initial) to run through
NPOP=50 ## number of individuals per generation; please keep this value below 99
Seeds=10 ## This is how many AraSim jobs will run for each individual## the number frequencies being iterated over in XF (Currectly only affects the output.xmacro loop)
FREQ=60 ## the number frequencies being iterated over in XF (Currectly only affects the output.xmacro loop)
NNT=40000 ## Number of Neutrinos Thrown in AraSim
exp=19 ## exponent of the energy for the neutrinos in AraSim
ScaleFactor=1.0 ## ScaleFactor used when punishing fitness scores of antennae larger than the drilling holes
GeoFactor=1 ## This is the number by which we are scaling DOWN our antennas. This is passed to many files
num_keys=6 ## how many XF keys we are letting this run use
database_flag=0 ## 0 if not using the database, 1 if using the database
## These next 3 define the symmetry of the cones.
PUEO=1 ## IF 1, we evolve the PUEO quad-ridged horn antenna, if 0, we evolve the Bicone
RADIUS=1 ## If 1, radius is asymmetric. If 0, radius is symmetric
LENGTH=1 ## If 1, length is asymmetric. If 0, length is symmetric
ANGLE=1 ## If 1, angle is asymmetric. If 0, angle is symmetric
CURVED=1 ## If 1, evolve curved sides. If 0, sides are straight
A=1 ## If 1, A is asymmetric
B=1 ## If 1, B is asymmetric
SEPARATION=0 ## If 1, separation evolves. If 0, separation is constant
NSECTIONS=2 ## The number of chromosomes
DEBUG_MODE=0 ## 1 for testing (ex: send specific seeds), 0 for real runs
## These next variables are the values passed to the GA
REPRODUCTION=3 ## Number (not fraction!) of individuals formed through reproduction
CROSSOVER=36 ## Number (not fraction!) of individuals formed through crossover
MUTATION=1 ## Probability of mutation (divided by 100)
SIGMA=5 ## Standard deviation for the mutation operation (divided by 100)
ROULETTE=20 ## Percent of individuals selected through roulette (divided by 10)
TOURNAMENT=20 ## Percent of individuals selected through tournament (divided by 10)
RANK=60 ## Percent of individuals selected through rank (divided by 10)
ELITE=0 ## Elite function on/off (1/0)
|
|
|
217
|
Wed May 10 17:43:20 2023 |
Alex M | How to run the loop | In this post, I'm going to give step by step instructions on everything you need to do to run the loop. See Julie's thesis for the most recent iteration of this manual. Also refer to entry 123 for a list of some errors we have encountered historically in the loop and how to resolve them, though some fixes may be outdated.
Running the loop
Getting started
Assuming you have followed the instructions from the onboarding tutorials, you should be ready to access OSC through the interactive website. Instead of using ssh to access OSC, the loop requires that you go to this website: https://ondemand.osc.edu/ . Login with your usual OSC credentials. Once there, you will need to request a Lightweight Desktop by clicking on "Interactive Apps" at the top of the page. See the screenshots attached for how to do this. Old documentation may refer to the Lightweight Desktop as a VDI.
You can request up to 24 hours for a Lightweight Desktop, and it should begin almost immediately. After you request it, the website will take you directly to the waiting page. You can navigate to this page yourself by clicking "My Interactive Sessions" at the top of the ondemand page. When the job begins, you will see a blue buttong that says "Launch Lightweight Desktop". Click it and you should have a new tab open that brings you to a remote desktop environment on OSC that you interact with through your browser.
New runs
If you're starting a new run for the first time (that is, beginning from generation 0), you will need to edit the script that runs the loop. Here is the path: /fs/ess/PAS1960/HornEvolutionOSC/GENETIS_PUEO/BiconeEvolution/current_antenna_evo_build/XF_Loop/Evolutionary_Loop/Loop_Scripts/Asym_XF_Loop.sh . At the top of the script is a list of variables that can be changed. See the first screenshot attached here.
For a new run, you must change the variable <RunName>, which is the first variable in the list. It should be in quotes and the convention is to start the name off with the date of the run, using YYYY/MM/DD format--this will always keep everything in chronological order when listing directories with <ls>. Other variables are explained in the comments next to them in Asym_XF_Loop.sh and you should change them depending on the type of run you are conducting.
To begin the loop, type in the command ./Loop_Scripts/Asym_XF_Loop.sh from the Evolutionary_Loop directory.
When the loop begins, you will be asked to press any key. After you hit a key, the loop will run Part A, which executes the GA using the <start> mode. It will then automatically move on to Part B, which creates the antennas in XFdtd. XF will ask you if you want to specify a location for the XF file to be saved. Click <No>. The loop will automatically save the XF directory into the run directory when it finishes with the first part of part B. In principle (that is, barring errors that stall the loop or interruptions due to the VDI job ending), you will never need to manually enter anything to the loop for it to run beyond this point.
However, if it is your first time using XF, you will need to set the max GHz setting upon startup to 2 instead of the default 10.
Continuing Runs
After starting a new run, the loop will run automatically. When your Lightweight Desktop job ends, you'll need to get another one repeat the steps above. You will not be prompted for any input.
Stepping Back
At times, you may want to continue the loop from an earlier point or interrupt the loop and step back. Usually you'll only want to do this within a generation, but it's possible that you will encounter an error or bug at the end of a generation and wish to return back to that point to remedy it before continuing forward in the next generation. This is a very tricky and delicate process that requires a lot of attention to detail. In the future, we'd like to make an option for the loop to do this automatically when given input at the beginning, but implementing that will take a long time and will be very sophisticated.
The state of the loop is recorded in the savestate file located here: /fs/ess/PAS1960/HornEvolutionOSC/GENETIS_PUEO/BiconeEvolution/current_antenna_evo_build/XF_Loop/Evolutionary_Loop/saveStates . The file will be named <Run_Name>.savestate.txt . In it, you will see three numbers. The first one represents the current generation of the loop. The second one represents the state of the loop, that is, which part in the generation it is currently on. The third one represents the individual it is processing. In practice, the third number is rarely relevant, and is almost always 1, though it can be used for Part B, where the loop is processing individuals sequentially, so if it was interrupted on individual eight (for example) you can change the number to be 8 so that it will pick up where it left off without needing to redo the first seven individuals.
If you want to step back to an earlier state in a generation, you'll need to interrupt the loop and revert the state by changing the second number in the savestate file. This is NOT all you will have to do, however. Because of the way files are edited and moved around during states, you will need to manually revert files to be in the format or location needed by the earlier state.
For example, you may need to revert from state 2 (when XF is creating the antenna geometries) to state 1 (when the GA generates new individuals). In this case, you'll need to edit the savestate file to change the second number from a 2 to a 1. Then, you'll need to change the generationDNA.csv file in Generation_Data to use the values from the previous generation, since the GA will have overwritten that file and uses it to determine what individuals are to be selected from. To do this, you'll need to locate the <gen>_generationDNA.csv file from the previous generation in the <RunName> directory in Run_Outputs. This is should be found here: /fs/ess/PAS1960/HornEvolutionOSC/GENETIS_PUEO/BiconeEvolution/current_antenna_evo_build/XF_Loop/Evolutionary_Loop/Run_Outputs/<RunName>/Generation_Data .
The above is a relatively simple example of how to step back in the loop. Stepping back from a late state to an early state will be more complicated, though if you're willing to sacrifice run time you can pretty easily follow the above to just restart a generation. Stepping back to a previous generation will be explained in a future update to this post. |
| Attachment 1: Ondemand_Front_Page.png
|  |
| Attachment 2: Ondemand_Interactive_Apps.png
|  |
| Attachment 3: Launching_Lightweight_Desktop.png
|  |
|
|
225
|
Wed Jun 14 14:38:22 2023 |
Alex M | PUEO Antenna Dimensions | Here are my recommended starting genes for the initial generation of the upcoming run (confirmed that these will produce a working antenna in XF). We want to use the lowest values we can because we expect that a larger (namely, taller) antenna will perform better:
S, H, x0, y0, yf, zf, beta
7.50000,50.0000,1.0000,1.00000,1.00000,50.0000,0.2
- S: Half the side length of the bottom of the antenna
- H: height of the antenna
- x0: distance of the bottom of the ridge from origin
- y0: width of ridge at the bottom
- yf: width of ridge at top
- zf: final height of the ridge (cannot exceed H)
- beta: a curvature parameter for the ridges
|
|
|
228
|
Thu Jun 29 12:05:45 2023 |
Alex M | Gain at various source heights | Here are a collection of antenna gain patterns with the antenna power source located at various heights at 500 MHz. The heights are indicated in the name of the images and were located at 3cm, 6cm, 12cm, and 24cm from the base. One thing to note is that the power source becomes longer as a function of height (since it's connected to the ridges, which slope back).
The 3D gain plots attached show the gain becoming more uniform until we get to the last one, where it seems to reinvert and be much stronger in the upward direction than below. I'll update this post with some polar slices for a more complete comparison between them.
EDIT: 07/17/23
I've made a few adjustments and added plots of them.
- First, I separated the ridges. Previously, the ridges touched at their inner corners. This electrically connected them and may be why we saw very high peaks in the first set of impedance plots. You can see the plots named Separated_Impedance_<x>_cm.png.
- This appears to have lowered the peaks considerably and also shifted them to lower frequencies. The peaks are still high when the source is placed high.
- We seem to be developing another peak at higher frequencies, although this also existed in the previous tests for the high sources.
- After this, I added a waveguide and positioned the source between the extensions of the ridges into the waveguide. I've also added a picture that shows the waveguide in the geometry.
- The sources here are positioned from 1 cm below the ridges to 8 cm below the ridges. The naming convention is the same as above, except it includes "Waveguide" in the name.
- The peaks are considerably lower here and seem consistent as we place sources further down. They are all below 500 Ohms, compared to as much as 4000 Ohms in the previous tests.
EDIT: 08/10/23
I've been trying more tweaks to the design to get rid of the peaks we see in the plots below. I'm having trouble actually getting the impedance to match close to the 50 Ohm value we expect from the cable. The best case situations seem to come from when the ridges are still touching, which we don't want. Here are the properties I've been changing:
- Ridge positions (gene in GA)
- We don't want the ridges to touch, but I can't get them to be very far from each other anyway. The minimum wavelength in our bandwidth would be 20 cm, but that's close to the size of the bottom of the antenna for when we make it large, so the separation is still small.
- When the ridges do touch is actually when I get the best matching,
- Bottom size (gene in GA)
- I've been changing the size of the bottom of the antenna. This is something that can change substantially between individuals in the GA, so even if I find a good value for this, the impedance it gives wouldn't be the same for all individuals we see in an evolution.
- This does seem to move the location of the impedance peak (in frequency) but I can't seem to get it fully out of band.
- Waveguide length
- I've been changing the length of the waveguide between 3 cm and 10 cm. We said that somewhere in the middle should be the most reasonable (the example antenna we saw looked to have a waveguide of ~5 cm long). It seems like the source position is more important.
- Source position
- I've been moving the position of the power source inside the waveguide. This seems to move around the peak and can lower its height, but I haven't been able to get peaks lower than ~400 Ohms, except in cases where the ridges are in contact.
I've added a picture of the best impedance I managed to get, but this involved an antenna with a small base and ridges touching. My next step is to just try a grid search by making many antennas automatically and simulating them all to look for any that have a nice impedance in our band. |
| Attachment 1: 3_cm.png
|  |
| Attachment 2: 6_cm.png
|  |
| Attachment 3: 12_cm.png
|  |
| Attachment 4: 24_cm.png
|  |
| Attachment 5: PUEO_Impedance_3_cm.png
|  |
| Attachment 6: PUEO_Impedance_6_cm.png
|  |
| Attachment 7: PUEO_Impedance_12_cm.png
|  |
| Attachment 8: PUEO_Impedance_24_cm.png
|  |
| Attachment 9: Separated_Impedance_3_cm.png
|  |
| Attachment 10: Separated_Impedance_6_cm.png
|  |
| Attachment 11: Separated_Impedance_12_cm.png
|  |
| Attachment 12: Separated_Impedance_24_cm.png
|  |
| Attachment 13: Separated_Waveguide_Impedance_1.png
|  |
| Attachment 14: Separated_Waveguide_Impedance_3.png
|  |
| Attachment 15: Separated_Waveguide_Impedance_6.png
|  |
| Attachment 16: Separated_Waveguide_Impedance_8.png
|  |
| Attachment 17: Best_Impedance_Plot_Horn_Antenna.png
|  |
|
|
239
|
Fri Sep 1 09:16:30 2023 |
Alex M | Curved Run With Realized Gain | We are beginning a new run with several improvements to the ARA VPol loop to try to evolve antennas that are optimally matched just by their geometry. To do this, we are evolving with the RealizedGain instead of just Gain in the Xmacros (thus taking into account impedance mismatch). We also have the speed up that parallelizes the AraSim jobs on each run. Attached is the run_details.txt file, but the GA parameters are subject to change. Here is what they are to begin:
We have a population size of 50 individuals per generation.
Selection operators (NUMBER selected by each):
- Roulette: 10
- Tournamente: 10
- Rank: 30
Genetic Operators (NUMBER generated by each):
- Reproduction: 6
- Crossover: 36
- Immigration: 8
- Mutation: 2
|
| Attachment 1: run_details_curved_realized.txt
|
####### VARIABLES: LINES TO CHECK OVER WHEN STARTING A NEW RUN ###############################################################################################
RunName='2023_08_30_realized_curved' ## This is the name of the run. You need to make a unique name each time you run.
TotalGens=100 ## number of generations (after initial) to run through
NPOP=50 ## number of individuals per generation; please keep this value below 99
Seeds=5 ## This is how many AraSim jobs will run for each individual## the number frequencies being iterated over in XF (Currectly only affects the output.xmacro loop)
FREQ=60 ## the number frequencies being iterated over in XF (Currectly only affects the output.xmacro loop)
NNT=1500 ## Number of Neutrinos Thrown in AraSim
exp=18 ## exponent of the energy for the neutrinos in AraSim
ScaleFactor=1.0 ## ScaleFactor used when punishing fitness scores of antennae larger than the drilling holes
GeoFactor=1 ## This is the number by which we are scaling DOWN our antennas. This is passed to many files
num_keys=4 ## how many XF keys we are letting this run use
database_flag=0 ## 0 if not using the database, 1 if using the database
## These next 3 define the symmetry of the cones.
RADIUS=0 ## If 1, radius is asymmetric. If 0, radius is symmetric
LENGTH=0 ## If 1, length is asymmetric. If 0, length is symmetric
ANGLE=0 ## If 1, angle is asymmetric. If 0, angle is symmetric
CURVED=1 ## If 1, evolve curved sides. If 0, sides are straight
A=0 ## If 1, A is asymmetric
B=1 ## If 1, B is asymmetric
SEPARATION=0 ## If 1, separation evolves. If 0, separation is constant
NSECTIONS=1 ## The number of chromosomes
DEBUG_MODE=0 ## 1 for testing (ex: send specific seeds), 0 for real runs
## These next variables are the values passed to the GA
REPRODUCTION=6 ## Number (not fraction!) of individuals formed through reproduction
CROSSOVER=36 ## Number (not fraction!) of individuals formed through crossover
MUTATION=2 ## Probability of mutation (divided by 100)
SIGMA=5 ## Standard deviation for the mutation operation (divided by 100)
ROULETTE=10 ## Percent of individuals selected through roulette (divided by 10)
TOURNAMENT=10 ## Percent of individuals selected through tournament (divided by 10)
RANK=30 ## Percent of individuals selected through rank (divided by 10)
ELITE=0 ## Elite function on/off (1/0)
ParallelAra=1 ## Sets whether AraSim is being run on multiple threads or not
|
|
|
162
|
Wed Jun 8 14:45:52 2022 |
Alan S | XF Simulations | ARA bicone in ice | PowerPoint Slides | Beam patterns with ARA bicone contained in a cylinder of air surrounded by a shell of ice.
|
| Attachment 1: XF_ARA_bicone_in_ice_and_air_column.pptx
|
|
|
182
|
Fri Sep 2 12:40:17 2022 |
Alan S | Ice Shell Around Bicone | Here is a PDF with a summary/log of my work trying to integrate an ice shell surrounding the bicone antennas in the GENETIS loop. I made gain patterns of the ARA bicone with the ice shells and without them, showing the impact of the ice on the antenna's gain. Having an ice shell changes these patterns, which are also dependent on the radius of the shell. I showed that convergence on the gain patterns and expected features start ocurring for shells with radii larger than 10 meters. I also keep track of the computation time which increases with bigger shells.
Note: I also add PowerPoint slides that contain all the graphs that I made. The PDF does not contain some of those since I didn't think they were coherent with my write-up, but I may be making an omission.
|
| Attachment 1: XF_ARA_bicone_in_ice_and_air_column.pptx
|
| Attachment 2: Far_Zone_Gain_of_ARA_Bicone_insice_Ice.pdf
|
|
|
146
|
Fri Feb 11 16:34:54 2022 |
Aidan Snyder | AREA - frequency linear dependence correlation test run - 01/18/2022 |
- Run Type
- Run Date
- Run Name
- Why are we doing this run?
- to see if the linear dependence on frequency was properly implemented
- What is different about this run from the last?
- attempted to evolve gain pattern as a linear function of frequency
- Symmetric, asymmetric, linear, nonlinear?
- Number of individuals (NPOP)
- Operators / Selection methods used (% of each)
- roulette crossover 50%
- roulette mutation 16%
- tournament crossover 18%
- tournament mutation 16%
- Are we using the database?
|
| Attachment 1: Screenshot_2022-02-11_164514.png
|  |
| Attachment 2: Screenshot_2022-02-11_164136.png
|  |
| Attachment 3: Screenshot_2022-02-11_164252.png
|  |
| Attachment 4: Screenshot_2022-02-11_164406.png
|  |
|
|
151
|
Fri Apr 8 16:06:31 2022 |
Aidan Snyder | AREA - frequency linear dependence correlation test run - 04/05/2022 |
- Run Type
- Run Date
- Run Name
- Why are we doing this run?
- to see if the linear dependence on frequency was properly implemented
- What is different about this run from the last?
- Under closer examination, the previous run of AREA appeared to not linearly depend on frequency, so we recompiled the GA in order to fix this
- Symmetric, asymmetric, linear, nonlinear?
- Number of individuals (NPOP)
- Number of neutrinos
- Operators / Selection methods used (% of each)
- roulette crossover 50%
- roulette mutation 16%
- tournament crossover 18%
- tournament mutation 16%
- Are we using the database?
- Result
- There is a problem with how the GA has assigned the Veff values, resulting in many individuals being assigned zero Veff, however the linear dependence seems to have been implemented successfully
Note: We also ran a run called 20220405fahimi5run1, which was a short test run with a very low amount of individuals and neutrinos which seemed to work fine; as in the linear dependence seemed to work. |
|
|
153
|
Tue Apr 19 17:46:07 2022 |
Aidan Snyder | AREA - Short run testing stringReplacement2.py - 04/19/2022 |
- Run Type
- Run Date
- Run Name
- Why are we doing this run?
- Check to see if stringReplacement2.py changes were successfull
- What is different about this run from the last?
- added below code in order to create a fitness file inside of each generation to display the fitness scores for just that generation, as opposed to just having one big file full of all the generations.
f2 = open(source + "/" + "gen_{}".format(gen) + "/fitnessFile_gen_{}".format(gen) + ".txt", 'a')
f2.write(','.join(mean_Veff_array) + "\n")
f2.close()
- Symmetric, asymmetric, linear, nonlinear?
- Number of individuals (NPOP)
- Operators / Selection methods used (% of each)
- roulette crossover 50%
- roulette mutation 16%
- tournament crossover 18%
- tournament mutation 16%
- Are we using the database?
|
|