Thread: Controlling variable values by printing on file

  1. #1
    Registered User
    Join Date
    Dec 2008
    Posts
    10

    Controlling variable values by printing on file

    Hello to everybody.
    I have this simulation that implements some physical system. I get my results on a file using function fprintf. It-s a long Montecarlo simulation that gets one result in about half an hour. I have to collect much results and I write them on the same file.
    My problem is:
    the file seem to get an update only when the simulation writes about 300 results, so I can't get a satisfying control on the results of my program.
    Is there a way to get results more often, or to control my variable in real time maybe (I'm not so used to programming language)?
    (I've already tried writing on the file with higher frequency, but I'd like to find a more straightforward way).
    Thank you very much

  2. #2
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Most likely, you would like to use fflush() to force the result out to the file itself. You can call fflush() after every fprintf(), or after a set number of fprintf().

    As long as you don't produce a lot of results every second, calling fflush() after each fprintf() should be fine.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  3. #3
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by p3rry View Post
    It-s a long Montecarlo simulation that gets one result in about half an hour. I have to collect much results and I write them on the same file.
    My problem is:
    the file seem to get an update only when the simulation writes about 300 results, so I can't get a satisfying control on the results of my program.
    If one result takes half an hour, 300 results will take 6 days. Why not just write to file every single time?
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  4. #4
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by MK27 View Post
    If one result takes half an hour, 300 results will take 6 days. Why not just write to file every single time?
    My guess is that the results are printed in bunches of (say) 4KB, which means that each result is about 12 characters (4096 / 300 = 13.6 characters).

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  5. #5
    Registered User
    Join Date
    Dec 2008
    Posts
    10

    thank you

    I'll try with fflush and then I let you know...
    Anyway thank you very much

  6. #6
    Registered User
    Join Date
    Oct 2008
    Location
    TX
    Posts
    2,059
    To control writing behavior to the output file you can use the setvbuf() call on the standard output stream. This can control the write frequency by using a custom buffer size instead of the default BUFSIZ used on Unix platforms.

  7. #7
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by itCbitC View Post
    To control writing behavior to the output file you can use the setvbuf() call on the standard output stream. This can control the write frequency by using a custom buffer size instead of the default BUFSIZ used on Unix platforms.
    That's correct. But to the programmer, it often offers MORE control to use fflush(), as it allows a flush to happen exactly where the programmer wants it. If you set a small buffer size with setvbuf(), the risk is that a large number of consecutive writes are being flushed individually, when an fflush() at the end of the sequence allows all of the writes to be done to the internal buffer, and then be flushed as one single write operation. Hence my suggestion to use fflush().

    In this particular case, I have a feeling it matters very little, but it's generally a better idea to flush() when some output is complete.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  8. #8
    Registered User
    Join Date
    Oct 2008
    Location
    TX
    Posts
    2,059
    I suggested setvbuf() only as an alternative since the OP wanted to see the simulation results before the process writes 300 times to the internal buffer. setvbuf() fits better where the op roughly knows how many records or characters to output before moving onto the next iteration. Both routines have their pros and cons though methinks in this case fflush() may very well be the way to go.

  9. #9
    Registered User
    Join Date
    Dec 2008
    Posts
    10
    I used fflush(). Thank you very much for your advices... bye!

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Can we have vector of vector?
    By ketu1 in forum C++ Programming
    Replies: 24
    Last Post: 01-03-2008, 05:02 AM
  2. Inventory records
    By jsbeckton in forum C Programming
    Replies: 23
    Last Post: 06-28-2007, 04:14 AM
  3. C++ std routines
    By siavoshkc in forum C++ Programming
    Replies: 33
    Last Post: 07-28-2006, 12:13 AM
  4. Simple File encryption
    By caroundw5h in forum C Programming
    Replies: 2
    Last Post: 10-13-2004, 10:51 PM

Tags for this Thread