Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Error while running make all #1

Open
hjsreehari opened this issue Jun 7, 2023 · 18 comments
Open

Error while running make all #1

hjsreehari opened this issue Jun 7, 2023 · 18 comments

Comments

@hjsreehari
Copy link

Hi,
I have installed hypre, mpi and hdf5. hypre is installed in usr/local/hypre.
However, when I run 'make all' from inoisy directory it shows the following
"
HYPRE_DIR not defined, trying 'usr/local/hypre'
h5pcc -g -Wall -Iusr/local/hypre/include -I/home/sreehari/Installers/inoisy/include -DHAVE_CONFIG_H -DHYPRE_TIMING -c /home/sreehari/Installers/inoisy/src/main.c -o /home/sreehari/Installers/inoisy/obj/main.o
/home/sreehari/Installers/inoisy/src/main.c:21:10: fatal error: _hypre_utilities.h: No such file or directory
21 | #include "_hypre_utilities.h"
| ^~~~~~~~~~~~~~~~~~~~
compilation terminated.
make: *** [Makefile:37: /home/sreehari/Installers/inoisy/obj/main.o] Error 1
"

When I specify full path for #include "_hypre_utilities.h" within the file main.c it shows
"fatal error: HYPRE_config.h: No such file or directory"

How can I solve this issue?
Thanks and regards,
Sreehari
@aviadlevis
Copy link
Collaborator

try running
export HYPRE_DIR=usr/local/hypre/src/hypre
before make all

@daelee6
Copy link
Collaborator

daelee6 commented Jun 8, 2023 •
edited
Loading

Hopefully Aviad's comment worked! When installing,hypre creates a second directory with the include and lib directories that need to be linked to inoisy, whose path is set by ./configure --prefix=<path>. Confusingly, this is by default <path-to>/hypre/src/hypre, creating a second directory named hypre inside the first. Either doing export HYPRE_DIR=<correct-path>, as Aviad suggested, or editing the Makefile should work.

@hjsreehari
Copy link
Author

Hi, I reinstalled hypre and provided the path as suggested in the Makefile. It worked.

However, when I run the next step
mpirun -np 8 general_xy -n 64 -solver 1 -pgrid 4 2 1 -output data

I get the following error
HDF5-DIAG: Error detected in HDF5 (1.10.4) MPI-process 0:
#000: ../../../src/H5F.c line 444 in H5Fcreate(): unable to create file
major: File accessibilty
minor: Unable to open file
#1 and so on ...
What is to be done in this case?

@daelee6
Copy link
Collaborator

daelee6 commented Jun 14, 2023

Looks like HDF5 is unable to create a file. Can you confirm the directory data exists? The arguments -output <dir> will attempt to write the output to the directory <dir>. A list of all arguments and their function can be found via ./general_xy -help.

@hjsreehari
Copy link
Author

hjsreehari commented Jun 15, 2023 via email

@hjsreehari
Copy link
Author

hjsreehari commented Jun 29, 2023 via email

@daelee6
Copy link
Collaborator

daelee6 commented Jun 30, 2023

Due to the way it is set up, the coordinates (t,x,y) have indices (k,j,i), so you would specify -nk 256 -nj 128 -ni 128 in the arguments when running (or you can simply do -n 128 -nk 256).

For the correlation lengths and the azimuthal correlation, you would go into src/param_general_xy.c and adjust the parameters and functions. The parameters param_lam, param_tau, etc. are set at the top, but you can build in the spatiotemporal correlations that you would like in the functions corr_length and corr_time.

For example, if param_lam = 5 (ostensibly in M, but really in arbitrary code units), you can specify in corr_length that the correlation length should just be equal to param_lam, or for it to scale as param_lam * r, or any other function that you desire, though more pathological functions may result in slow convergence or a failure to converge.

The parameters param_lam, etc. are set up so that it is possible to change the length of the correlation at runtime by reading in a parameter file, while keeping the form of the correlation fixed in the function corr_length/time. The parameter file to read in can be specified via -params <file>.

@hjsreehari
Copy link
Author

hjsreehari commented Jul 2, 2023 via email

@daelee6
Copy link
Collaborator

daelee6 commented Jul 5, 2023

It should be sufficient to return 1, or return param_tau and set param_tau to 1.

You can view the spatial correlation as described by an ellipse at each point. lam1 is the length of the major axis of this ellipse, lam2 is the length of the minor axis. and theta is the rotation of this ellipse, usually set to be oriented in the direction of the pitch angle. The azimuthal correlation will be some function of these parameters, which can be worked out geometrically.

@hjsreehari
Copy link
Author

hjsreehari commented Jul 6, 2023 via email

@hjsreehari
Copy link
Author

hjsreehari commented Dec 27, 2023 via email

@daelee6
Copy link
Collaborator

daelee6 commented Jan 2, 2024

The total time duration is set in the param file as param_x0start and param_x0end, in terms of M, and the number of timesteps is set on runtime using the flag -nk <number>. So the time resolution will be (x0end - x0start) / (# timesteps), set by those parameters.

@hjsreehari
Copy link
Author

hjsreehari commented Jan 3, 2024 via email

@hjsreehari
Copy link
Author

hjsreehari commented Jan 16, 2024 via email

@daelee6
Copy link
Collaborator

daelee6 commented Jan 16, 2024

It depends on what you're trying to get out. The random field in inoisy is generated from a white noise process whose seed is set by the environment variable GSL_RNG_SEED. If this is not changed, both runs will receive the same white noise, so regardless of the temporal resolution the first three snapshots will be very similar.

If it is okay to have completely different realizations for each run, you can simply set GSL_RNG_SEED=<seed number> before every run or just randomize it as you run inoisy, for example like:
GSL_RNG_SEED=${RANDOM} mpiexec -n 4 ./general_xy -n 64 -nk 128 -pgrid 1 1 4

If the runs need to look "similar", it would require a bit more surgery. inoisy has the ability to read in an input source term. For example, you could generate a white noise process at 0M, 1M, 2M, etc., shared between the two runs, and add in more white noise components at 0.5M, 1.5M, 2.5M, etc. for the run with finer temporal resolution. Because these components are independent, this is still a valid source field, except that now these two runs are no longer independent. (This does not mean that these runs will be identical on the integer M steps, since the resulting GRF is a solution over the entire source field.)

@hjsreehari
Copy link
Author

hjsreehari commented Jan 17, 2024 via email

@daelee6
Copy link
Collaborator

daelee6 commented Jan 22, 2024

I could think of a few ways to approach this. The simplest way would be to just generate a single run at a cadence of 0.5M, from which you could take every other timestep to artificially get a lower temporal resolution.

Generating a source field that matches at integer M times, which I mentioned earlier, would generate two runs that are similar at those times, but not identical. If this is alright, creating a python script to do this should be relatively straightforward.

If a light curve is all that is needed, simply generating them (or interpolating, depending on the exact details of the problem) with standard methods for Gaussian processes seems like a reasonable solution as well. In the end, inoisy generates a Gaussian random field, and a light curve generated from a GRF will still be a Gaussian process, though with an unknown covariance function.

@hjsreehari
Copy link
Author

hjsreehari commented Jan 24, 2024 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@aviadlevis @daelee6 @hjsreehari