# Storing Data From C++ Program to a file.

• C/++/#
I am using a verlet algorithm in c++ to model the motion of a satellite, and want to output position and velocity data from each timestep so that I can then read it into MATLAB and plot graphs to see how well my model matches the 'real life' graphs. so far I have at the end of each iteration:

Code:
    ofstream fout; bool ok;

ok = false;
do{
fout.clear();
fout.open("height_data.dat");
if (fout.good()) ok = true;
}while (!ok);

fout<<height<<endl; //height is the variable with current position to output and store

fout.close();

As far as I have been taught, this should create the file height_data.dat in the same location as the c++program, but it doesn't.
I am also unsure about adding new data at each timestep without erasing previous data, and wondered if it is possible to store time, height and velocity all in one file to use with MATLAB?

Any hints on if and how I can achieve this would be greatly appreciated.
:)

Last edited by a moderator:

Borek
Mentor
As far as I have been taught, this should create the file height_data.dat in the same location as the c++program
More like it should create a file in a current directory - whichever it is for your program. Doesn't have to be neither directory where the source is nor where the executable is. Details will depend on OS and configuration.

D H
Staff Emeritus
I am using a verlet algorithm in c++ to model the motion of a satellite, and want to output position and velocity data from each timestep so that I can then read it into MATLAB and plot graphs to see how well my model matches the 'real life' graphs. so far I have at the end of each iteration:

Code:
    ofstream fout; bool ok;

ok = false;
do{
fout.clear();
fout.open("height_data.dat");
if (fout.good()) ok = true;
}while (!ok);

fout<<height<<endl; //height is the variable with current position to output and store

fout.close();
You don't want to do this for a number of reasons.

One problem is the call to open. The version of the open call you are using will blow away the previous version of the file. You will get a file containing one entry for the very last step. This can be fixed by opening the file in append mode, but that isn't the right solution.

Opening and closing files are very expensive operations. Formatted output is also expensive, but not near as expensive as opening and closing. Doing this every time step turns your fast but inaccurate verlet method into a ridiculously slow (but still inaccurate) technique. What you should be doing instead is to open the file at the start of your run, writing to it occasionally (more on this later), and closing it when finished.

How often should you record? Not every step, particularly so for something like verlet. Verlet is a second order technique. To get anything close to reasonable accuracy you need to take very, very small time steps with verlet. If, for example, you are simulating an object that is circularly orbiting some other object, you need to have the time steps be such that the object moves about 1/1000 of a degree per step. Make your time steps smaller and you will start running into truncation error problems. Make your time steps bigger and you will start running into limitations of the verlet method itself. If you record every step you will have 360,000 or so points per orbit. You don't need anything close to this number of points. If you instead add an entry to the file for every ten or even 100 integration steps you will still see everything you need to see in a graph, and your program will run a whole lot faster.

Now for some individual snippets:

Code:
    ok = false;
do{
fout.clear();
fout.open("height_data.dat");
if (fout.good()) ok = true;
}while (!ok);
Why bother with the loop? If you don't open the file successfully the first time around, what makes you think it will work the second, or third, or thousandth time around? Some errors are fatal. There is no recovery from them. Failing to open a key output file is one of those fatal kinds of errors. There's no point in continuing the run if you can't record the results, and there's not much you can do to recover from the error. You are doing nothing to recover from the error other than retrying the same command over and over (and over and over). It won't work. It's much easier to write an error message to standard output and exit the program if the open call doesn't work.