empty 'results' file created during each run

[billsacks]

From @matthewhoffman on August 20, 2015 16:19

It looks like the 'results' file gets created in libglimmer/writestats.c, line 95. I'm not sure what this code is doing but I'm pretty sure we aren't using it.

Copied from original issue: E3SM-Project/cism-piscees#41

[billsacks]

From @jhkennedy on August 20, 2015 17:52

When I run any of the test cases on my linux machine, the *.results file typically looks like:

#cfg_file             wall_time  usr_time   sys_time  date              host       arch    version    FCFLAGS
slab.0030.config      1.04       1.03       0.02      2015-08-20_13:20  pc0101123  x86_64  2.0.0      "(Not reported in cmake build)"

(I cleaned up the white space above -- it's not near as clear in the file)

The results file gives us the run timing information for the LIVVkit performance metrics when CISM was run on a mac (i think) or linux box. If CISM is build with the gptl timing libraries (ie titan, hopper), then the results file isn't produced, and a set of *.cism_timing* files are produced.

( @arbennett may want to comment here as he wrote the LIVVkit parsers )

However, we can generate this file on our own in the test run files with the time command and so, could be removed from CISM source entirely.

---

I also see that in the results file, the version is still being reported as 2.0.0, so that should probably be bumped to 2.0.5 in #40 . Do you know where that version number is coming from?

[billsacks]

From @matthewhoffman on August 20, 2015 19:30

Hmm, that's interesting. I did think the results file contained some sort of summary information about the run, but on my machine it is an empty file.

The version number used to be pulled in correctly in the old autotools build, but there was some technical reason why it was hard to get this to happen when we moved over to cmake. I don't remember the details. Doug Ranken might.

I think right now the version number is defined here:
utils/build/config.inc_generator/config.inc.cmake.in:#define VERSION "2.0.0"
and has to be manually updated somehow.

[billsacks]

From @worleyph on August 20, 2015 19:42

The "results file" logic is disabled when using GPTL. It works poorly for parallel runs (information is difficult to interpret, and is pretty meaningless in my opinion), and can be VERY expensive. I don't know why it would still try to write a results file though. It didn't used to.

[billsacks]

From @jhkennedy on August 20, 2015 19:43

Thanks @worleyph. I've never seen it write a results file when using GPTL, are you seeing that @matthewhoffman? Or is it no GPTL, but also empty?

[billsacks]

From @stephenprice on August 20, 2015 20:5

@jhkennedy , my build is w/o GPTL and the file is also empty.

[billsacks]

From @jhkennedy on August 20, 2015 20:7

Well, that is interesting. Both macs I assume, @matthewhoffman and @stephenprice? @arbennett, is the results file empty for you on mac?

[billsacks]

From @whlipscomb on August 20, 2015 20:14

@jhkennedy , I can confirm that for a Mac build without gptl, my results file is empty. I think this is a leftover from serial/automake/Glimmer days. I'd be happy to have it go away if someone wants to take that on.

[billsacks]

From @jhkennedy on February 3, 2016 15:32

LIVV is undergoing an update and will no longer be processing the results files (GPTL only), so this should be removed entirely from the CISM source.

I've assigned this to myself, and will take care of it in my BATS-update branch.