[ET Trac] [Einstein Toolkit] #1743: Reduce number of output files per directory

[Einstein Toolkit]

#1743: Reduce number of output files per directory
-----------------------+----------------------------------------------------
  Reporter:  eschnett  |       Owner:                     
      Type:  defect    |      Status:  review             
  Priority:  unset     |   Milestone:                     
 Component:  Other     |     Version:  development version
Resolution:            |    Keywords:                     
-----------------------+----------------------------------------------------

Comment (by knarf):

 Replying to [comment:13 eschnett]:
 > Replying to [comment:12 knarf]:
 > > > This is a special case, since {{{ilog(0)}}} is not defined.
 > >
 > > We could define it. The "Number of processes that can access the same
 directory" being 1 doesn't seem to be unreasonable to me.
 >
 > It's "log of the number of processes minus one", and "log of zero" is
 undefined. Running on one process is truly a special case.

 I meant 'we can (re)define what ilog(0) is, different from the definition
 for values >0. If I read the comment for the parameter correctly,
 restricting the number of processes that can access the same directory to
 1 isn't something so special. Each process would write into it's own
 directory. That is different from running on one process.

 > The fact that you cannot have just one file per directory is different.
 The subdirectories form a tree; if each tree branch has just 1 child, then
 the tree would be infinite. That's a limit on the use parameter
 {{{processes_per_directory}}}.

 I am afraid, but I think I don't understand the meaning of the parameter.
 I assumed: For a value of '1' I would expect each process to write into a
 different directory. For a value of '2' I would expect 2 processes to
 share one directory, and so on. A value of '0' would be special, as all
 processes could write to the same directory in that case. Isn't that how I
 should interpret the parameter?

 > > I do understand that a wrong usage of both strncat and strncpy can
 lead to problems much like the usage of strcat and strcpy. I don't
 understand why that should prevent us from using them correctly. Right
 now, with asserts possibly doing nothing, both strcat and strcpy could
 write into memory they shouldn't touch.
 >
 > I refuse to do that. I'll convert the file to C++ instead.

 That would be fine too, of course. string handling in C is painful even if
 done correctly.

 > Sure. I'm actually with you on this -- I don't like the style, and I'm
 serious about changing the style with an automated tool.

 I don't have enough experience with tools like this to have an informed
 opinion. I didn't quite like what a quick try using clang-format did to my
 source, but that is more my lack of configuration than anything else.

-- 
Ticket URL: <https://trac.einsteintoolkit.org/ticket/1743#comment:14>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit