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.

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

Fixed #21 - missing gsl_vector_free() call for 365 isotope bug. #22

Merged
merged 116 commits into from
Aug 29, 2022

Conversation

jayjaybillings
Copy link
Collaborator

Signed-off-by: Jay Jay Billings jayjaybillings@gmail.com

…neInterpolator interpolateT (hydroLines, hydroTime, hydroTemp) object is being created correctly.
…and torch49, but oscillations at late times in nova case.
…and torch49, but oscillations at late times in nova case.
…ion. No more oscillations. Nova and torch47 profiles look reasonably good.
…ion. No more oscillations. Nova and torch47 profiles look reasonably good.
…ion. No more oscillations. Nova and torch47 profiles look reasonably good.
…n temperature. Appears to be interpolating correctly in both temperature and density.
…off. Added the corrections from guidry_dev1 branch to read last column in rates file output now by Java, and increased the size of character array to keep from cutting off the reaction string.
… Basic problem caused by java code outputting a -1 for the RG class for reactions of the form a+b->c+d+e+f. The -1 then gets used as an index, wreaking some havoc on determining quantitites like niso, which caused loops to go out of bounds. Fixed by defining a new RGclass=6, which corresponds to a bookkeeping class of the form a+b<->c+d+e+f, which will always have only one member (e.g., he3+li7-->n+p+he4+he4 is the only reaction in RG class 21 in the nova simulation) because ReacLib contains no 4-body reactions that could be the inverse. Now on read-in if the RG class is -1, it is converted automatically to 6. Should fix the Java code to output 6 instead of -1 for such cases so the conversion of -1 in the C++ code would no longer be required.
…lotsteps=50. Runs but gnufile is null for 100 plot steps.
…cation that the computation is not taking so long, but the i/o is very slow.
…uring run, as much as 84% of machine memory was being taken, so probably encountering memory problems for very large networks. This may be because we are storing so much stuff to plot at the end, and because some arrays are static and taking more space than required in some calculations.
…hole machine and using about 82% of the memory.
guidrymwg and others added 19 commits August 12, 2022 11:29
…y with new step by step output files (data now in plot1.data, plot2.data, plot3.data, plot4.data.
…imestep to external files for later plotting. Thus we should no longer need the large arrays that are holding data to be output to data files at the end. Will switch now to new branch guidry_debugPlotOutput2 and begin removing those arrays and the statements to write the data to arrays.
…data to files to store until the end of the calculation. Checked that all plotting was still possible from the files plot1.data, plot2.data, plot3.data, and plot4.data, which are written to at each plot output step and not stored in the program.
…rgets[plotSteps], since we are outputting all plot data at each timestep to external files, rather then storing in arrays until the end of the calculation, where we were then writing those arrays to data files. Should greatly reduce the memory use.
…d rather than gap = nextPlotTime - t_saved to keep timestep from exceeding next plot step by too much.
Signed-off-by: Jay Jay Billings <jayjaybillings@gmail.com>
Signed-off-by: Jay Jay Billings <jayjaybillings@gmail.com>
@jayjaybillings
Copy link
Collaborator Author

Merged Mike's most recent changes from guidry_debugPlotOutput2.

@guidrymwg
Copy link
Contributor

guidrymwg commented Aug 17, 2022 via email

@jayjaybillings
Copy link
Collaborator Author

Your version calls gsl_vector_free(rv2minus) on line 2334 when it is uncommented, which is after the function exits with return 0 or return 2 as shown here:

       rv2minus = gsl_vector_alloc(ISOTOPES);
        gsl_vector_memcpy(rv2minus,rv2);
        gsl_vector_scale(rv2minus,-1);
        kk = gsl_vector_equal(rv1,rv2minus);
        
        if(kk==0){
            
            return 0;  // rv1 not equal to rv2 and not equal to -rv2
            
        } else {

            return 2;  // rv1 equal to -rv2

        }
        
        //gsl_vector_free(rv2minus);
        
    }    // End function compareGSLvectors

That won't work. You have to call it before the if statements as I did here because the function has always executed due to it being an if/else statement:

       gsl_vector * rv2minus = gsl_vector_alloc(ISOTOPES);
        gsl_vector_memcpy(rv2minus, rv2);
        gsl_vector_scale(rv2minus, -1);
        kk = gsl_vector_equal(rv1, rv2minus);


        // Free the vector. Better solution would be to globally allocate
        // this and remove the repeated allocation all together.
        gsl_vector_free(rv2minus);

        if(kk==0){

            return 0;  // rv1 not equal to rv2 and not equal to -rv2
            
        } else {
            return 2;  // rv1 equal to -rv2
        }
        
    }    // End function compareGSLvectors

…o free a GSL vector memory allocation. For the Nova134 test case memory usage is reduced from 17.4% to 0.1%.
@Rchari1 Rchari1 merged commit 89429f1 into master Aug 29, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants