The ascii data model for initial composition model setting does not function well

Hello folks,

I tried to run a test similar to the jellyfish case (geomIO.prm for section 5.2.12 in the manual) but for a 3D case. Indeed, geomIO.prm works well. But, my 3D case doesn’t work through.

The relevant settings in the prm file:
subsection Initial composition model
set Model name = ascii data
subsection Ascii data model
set Data directory =/home/dealii/aspect/model_input/aspect/model_input/data/
set Data file name = test3D_composition.txt

Here is the file test3D_composition.txt:
#POINTS: 2 2 3
#x y z phases
0.0 0.0 0.0 0.0
3.0 0.0 0.0 0.0
0.0 3.0 0.0 0.0
3.0 3.0 0.0 0.0
0.0 0.0 2.0 1.0
3.0 0.0 2.0 1.0
0.0 3.0 2.0 1.0
3.0 3.0 2.0 1.0
0.0 0.0 4.0 2.0
3.0 0.0 4.0 2.0
0.0 3.0 4.0 2.0
3.0 3.0 4.0 2.0

The output looks like
Exception ‘ExcMessage("Invalid coordinate " + Utilities::int_to_string(column_num) + " in row " + Utilities::int_to_string(row_num) + " in file " + filename + "\nThis class expects the coordinates to be structured, meaning " "the coordinate values in each coordinate direction repeat exactly " “each time.”)’ on rank 4 on processing:

An error occurred in line <364> of file </home/dealii/aspect/source/> in function
void aspect::Utilities::StructuredDataLookup::load_file(const string&, const MPI_Comm&) [with int dim = 3; std::__cxx11::string = std::__cxx11::basic_string; MPI_Comm = int]
The violated condition was:
old_value == 0. || (std::abs(old_value-temp_data) < 1e-8*std::abs(old_value))
Additional information:
Invalid coordinate 2 in row 3 in file /home/dealii/aspect/model_input/aspect/model_input/data/C_3D_MohoErosion.txt
This class expects the coordinates to be structured, meaning the coordinate values in each coordinate direction repeat exactly each time.


**The coordinates make sense. The system gives such hints. Weird. **

Has anybody met similar issue?


Dear Shaozhuo,

Have you tried adding a single whitespace between # and POINTS:, i.e.
# POINTS: 2 2 3?

The version of ASPECT that I have installed at the moment requires the single space, but I don’t know whether that will solve your problem.

Dear Bob,

The original format used in the simulation has a single whitespace between # and POINTS. When I typeset it in this forum, I make such a mistake, missing the whitespace.

The ascii data model for setting 3D temperature variations works well. The ascii data model for 3D composition model has similar format. But, it doesn’t work. Why is it so weird?


I can’t recreate the issue using the current master branch. I have tried the file with and without CR as the last byte in the file.

I’ve attached the prm file I used to test your input. I changed the location and the name of the file, so you’ll need to make sure that you have files in the correct places.

Could you test this?

  • If it doesn’t work, could you post the version of ASPECT that you’re using?
  • If it does work, we’ll need more data to work out exactly what your problem is (i.e. a minimum non-working example prm)

ascii_data_initial_composition_3d_box.prm (2.2 KB)
box_3d.txt (239 Bytes)

Another possibility: maybe this file is the one with the problem?

I sincerely thank you for helping me fixing this issue!
Your prm file can be tested. Before getting your files, I used a similar ascii data file as your box_3d.txt, but I got the same errors. Let me compare your and my prm files carefully and then I will post my issues. The issue might lie in the prm file.

I am curious about the setting in your prm file:
subsection Compositional fields
set Number of fields = 1

Why does the number of field equate to 1?
In my case, it should be equate to 2. That is, three materials: the background and the other two.


Ah, your question is a good one, explains why you’re having problems.

In ASPECT, each compositional field is a scalar field; that is, the “composition” has a float value at every point in the domain. So in your test3D_composition.txt, you are currently defining a single compositional field which has a value between 0 and 2. ASPECT will interpolate between the grid points in the file and then the appropriate plug-in(s) will interpret what that value means.

ASPECT doesn’t currently allow users to specify material type by integer value in a single compositional field. This would potentially be a good thing to have (it would be less-memory intensive), but such changes would require careful treatment to ensure that mass conservation is (approximately) satisfied. Instead, ASPECT allows implementation of three-material models using two compositional fields which represent the proportions of the non-background materials:

# POINTS: 2 2 3
# x y z proportion_material_1 proportion_material_2
0.0 0.0 0.0 0.0 0.0
3.0 0.0 0.0 0.0 0.0
0.0 3.0 0.0 0.0 0.0
3.0 3.0 0.0 0.0 0.0
0.0 0.0 2.0 1.0 0.0
3.0 0.0 2.0 1.0 0.0
0.0 3.0 2.0 1.0 0.0
3.0 3.0 2.0 1.0 0.0
0.0 0.0 4.0 0.0 1.0
3.0 0.0 4.0 0.0 1.0
0.0 3.0 4.0 0.0 1.0
3.0 3.0 4.0 0.0 1.0

If you use this layout, ASPECT should run fine.

Yes. Your sharp eyes find the solution!!!

I set three materials in the Material model subsection, using the subsection Multicomponent option. I believed that the numbers for the last column, even though they are float number, have a one-to-one correspondence with the materials. In that case, I always got the errors as shown at the very beginning of this post.

Now, following your suggestion, everything goes well. This issue puzzled me in the last 1-2 months. I hope others, who meet similar issue, will learn from this post.

Thank you very very much!