Time dependent ascii data issue for boundary traction

[mfmweerdesteijn]

I want to use ascii data for the boundary traction on the top surface. It works well for when I specify 'Data file name' completely, such as 'box_3d_top.0.txt'. But as soon as I introduce time dependency and use 'set Data file name = box_3d_top.%d.txt' I get the following errors:

`Exception 'ExcMessage (std::string("Ascii data file <") + filename + "> not found!")' on rank 191 on processing:

---

An error occurred in line <756> of file </cluster/projects/nn9283k/Aspect/maaike/aspect_github/source/structured_data.cc> in function void aspect::Utilities::AsciiDataBoundary::initialize(const std::set&, unsigned int) [with int dim = 3] The violated condition was: Utilities::fexists(filename) || filename_is_url(filename) Additional information: Ascii data file </cluster/home/maaike/short/aspect_rho_p_ascii/asciidatabt/box_3d_top.415199840.txt> not found!

Stacktrace:

0 /cluster/projects/nn9283k/Aspect/maaike/aspect_github/build_main_d2/aspect: aspect::Utilities::AsciiDataBoundary<3>::initialize(std::set<unsigned int, std::less, std::allocator > const&, unsigned int)

1 /cluster/projects/nn9283k/Aspect/maaike/aspect_github/build_main_d2/aspect: aspect::BoundaryTraction::AsciiData<3>::initialize()

2 /cluster/projects/nn9283k/Aspect/maaike/aspect_github/build_main_d2/aspect: aspect::Simulator<3>::Simulator(ompi_communicator_t*, dealii::ParameterHandler&)

3 /cluster/projects/nn9283k/Aspect/maaike/aspect_github/build_main_d2/aspect: void run_simulator<3>(std::cxx11::basic_string<char, std::char_traits, std::allocator > const&, std::cxx11::basic_string<char, std::char_traits, std::allocator > const&, bool, bool, bool)

4 /cluster/projects/nn9283k/Aspect/maaike/aspect_github/build_main_d2/aspect: main

---

Aborting!`

It cannot find 'box_3d_top.415199840.txt' (this is a random different number for each processor). Whilst it should look for 'box_3d_top.0.txt' but I don't understand how the random long number creeps in (It also happens when I use 'set First data file number = 0 '), I also do not understand from looking through the source code (source/structured_data.cc).

example prm file and log file for time independent boundary traction that works: aspect_rho_p_ascii_working.txt aspect_rho_p_ascii_working_log.txt

example prm and log file for time dependent boundary traction that doesn't work: aspect_rho_p_ascii_notworking.txt aspect_rho_p_ascii_notworking_log.txt

Here are some ascii files I am using: box_3d_top.0.txt box_3d_top.1.txt box_3d_top.2.txt box_3d_top.3.txt box_3d_top.4.txt

[mfmweerdesteijn]

I found what went wrong: If you want to have time-dependency, you need to use both %s for the boundary and %d for the file number. So even if there is only one boundary specified at 'Prescribed traction boundary indicators', you cannot use 'box_3d_top.%d.txt', you have to use 'box3d%s.%d.txt' for the 'Data file name'. Otherwise 'replace_placeholders' in 'source/structured_data.cc' doesn't do its job, and a number between -2147483648…2147483647 (inclusive) is chosen.

Should we make a note about this somewhere?

[gassmoeller]

Hi Maaike, thanks for the report. I looked into the algorithm in replace_placeholders and you are right with your interpretation. Because of the way the function is written, we correctly handle three cases for the name of the file: 1. Do not specify any placeholder ('box_3d_top.0.txt' as you mentioned above). 2. Specify both placeholders in the order boundary name - time step (as in 'box3d%s.%d.txt'), you could change your file name to this and it should work. 3. Specify only the boundary name as placeholder (as in ''box3d%s.0.txt').

However, only specifying the time step as placeholder like you did above creates a bug, where the function takes the boundary name and tries to convert it into a number and put it into the file name. Also swapping the order of the boundary name and time step would trigger a similar bug. Unfortunately, due to how the function is written at the moment this case is hard to test for in the code. We should at least improve the parameter description though. This would be in 'structured_data.cc' 1172-1176. Do you want to give it a try?

[mfmweerdesteijn]

Function remained the same but function description improved in PR #5201