Problem with exporting an ODF as a lossless ASCII file

[aplowman]

What do you want to do? Export an ODF to a lossless ASCII file, as documented here.

What data do you have? A model ODF.

What code do you use? Please provide minimalist code with code in the following form

cs = crystalSymmetry('hexagonal');
ori = orientation.byMiller([0 0 1], [1 0 0], cs);
model_ODF = unimodalODF(ori, 'halfwidth', 10*degree);

% (1) Export to a lossy ASCII file:
export(model_ODF, 'odf.txt', 'Bunge')

% (2) Export to a lossless MTEX ASCII file (?):
export(model_ODF, 'odf.mtex', 'Bunge', 'MTEX')

% (3) Export to a lossless MTEX ASCII file (?):
export_mtex(model_ODF, 'odf.mtex', 'Bunge')

What result do you get Lines commented (1) and (2) seem to give the same text file. Line commented (3) fails with the error message listed below.

What result do you expect Based on the documentation, I expect line commented (2) to produce a distinct file from line commented (1). I expect line commented (2) to produce an ASCII text file that is lossless.

Error Message If you get an error message copy and paste it below The error message recieved when using the export_mtex function directly (line commented (3)) is:

Unrecognized method, property, or field 'psi' for class 'ODF'.

Error in ODF/export_mtex (line 53)
    fprintf(fid,'%% kernel: %s\n',char(odf(i).psi));

Error in minimal_example (line 13)
export_mtex(model_ODF, 'odf.mtex', 'Bunge')

What MTEX version do you use? 5.3.1 on Matlab R2019b.

Thanks!

[kilir]

Hi, could you test the fix? https://github.com/mtex-toolbox/mtex/commit/ebdefed0fe42f7204e4cf62c1342ff6171c4caf8

To call the mtex interface, use 'interface', 'mtex'. I updated the documentation accordingly.

Cheers, Rüdiger

[ralfHielscher]

Hi Adam,

may I ask why you want to export the ODF in this format. A more simple way for lossless export is to save it as a mat file by

save('file.mat','odf')

Ralf.

[aplowman]

Thanks for the fix @kilir. I can indeed now use 'interface', 'mtex' to export the ODF. However, I believe there might still be an issue. Consider the following snippet, in which we generate a model unimodal ODF, export as a lossless ASCII file, and finally attempt to reload the ODF into a new variable from that file:

clear;

halfwidth = 15;

cs = crystalSymmetry('hexagonal');
ori = orientation.byMiller([0 0 1], [1 0 0], cs);
modelODF = unimodalODF(ori, 'halfwidth', halfwidth*degree);

% Export to a lossless MTEX ASCII file:
export(modelODF, 'odf.mtex', 'Bunge', 'interface', 'mtex');

% (1) Reload ODF from this file using `loadODF_generic`:
modelODF_mtex = loadODF_generic(...
    'odf.mtex',...
    'cs', cs,...
    'Bunge',...
    'ColumnNames', {'Euler 1' 'Euler 2' 'Euler 3' 'weight'}...
);

% `modelODF_mtex` incorrectly(?) has a halfwidth of 10 degrees:
disp(rad2deg(modelODF_mtex.components{1}.psi.halfwidth));

I could be misunderstanding something, but the reloaded ODF (component) now has a different halfwidth (10 degrees instead of the original 15 degrees). Is this correct?

If I instead use the ODF.load method to reload the ODF like this:

% (2) Reload ODF from this file using `ODF.load` (results in error):
modelODF_mtex = ODF.load(...
    'odf.mtex',...
    'Bunge',...
    'ColumnNames', {'Euler 1' 'Euler 2' 'Euler 3' 'weight'}...
);

...I receive an error:

Error using check_interfaces (line 53)
Could not detect file format. You may ask for help in the MTEX
forum (https://groups.google.com/forum/#!forum/mtexmail).

Error in loadData (line 79)
  [interface,options] =
  check_interfaces(fname{1},type,varargin{:});

Error in ODF.load (line 31)
[odf,interface,options] = loadData(fname,'ODF',varargin{:});

Error in minimal_example (line 24)
modelODF_mtex = ODF.load(...

Thanks!

[aplowman]

Hi Adam,

may I ask why you want to export the ODF in this format. A more simple way for lossless export is to save it as a mat file by

save('file.mat','odf')

Ralf.

Hi @ralfHielscher, yes of course. I am writing a computational workflow management code in Python called MatFlow, which allows users to write coherent, reproducible "workflows" that can utilise multiple distinct materials science software packages. For this to work, each type of data that might exist within the workflow (e.g. an ODF) should be represented transparently, because the data may have to "flow" through different software packages that might each have their own internal representation. For example, a model ODF generated by MTEX should, in MatFlow, be represented in the same way as a model ODF generated by some other package (maybe Dream.3D). I therefore much prefer to work with data in a non-binary/non-proprietary format where it is reasonable to do so, which I believe is the case here.

(That is not to say that MatFlow cannot work with binary/proprietary data formats, rather it makes things easier for me and for users to understand what the workflow is doing, which is especially useful during the current, early development phase of MatFlow!)

[kilir]

Hi Adam, your observation is correct. That's basically due to the fact that the import function which reads in the kernel information. That should be easy to add.

However, currently export_mtex does not iterate through all odf components which might probably be a good idea to have as well, (as well as Fourier ODFs are not supported) so for the time being, the export won't support all ODFs types.

Cheers, Rüdiger