| Re: weird output in ".dat#" ( No.1 )|
- Date: 2017/03/23 17:33
- Name: T. Ozaki
A tab which is invisible should not be included in an input file.
Your problem might be the case.
| Re: weird output in ".dat#" ( No.2 )|
- Date: 2017/03/23 19:59
- Name: Pui-Wai (Leo) Ma <firstname.lastname@example.org>
- Dear Prof. Ozaki,
Thank you very much. You are correct. It resolved the issue.
| Re: weird output in ".dat#" ( No.3 )|
- Date: 2017/03/24 22:40
- Name: Kylin
- Dear TO
I also discovered the similar problem for dat file. To my point of view, we should make the software more convenient to use and add more Fool-proofing steps to avoid the potential error.
Currently I am reviewing the code of openmx and would like to make some contribution to openmx. But now I just want to modify the input of openmx and make it more convenient to use and allow the read of extra atom coordinate file. But how could I send the modified code to you? Actually I prefer to do it in github, maybe you could setup a github project? which would be benefit for everyone who want to contribute their effort to openmx
| Re: weird output in ".dat#" ( No.4 )|
- Date: 2017/03/25 00:19
- Name: Artem Pulkin
- " ... would like to make some contribution to openmx. But now I just want to modify the input of openmx and make it more convenient to use and allow the read of extra atom coordinate file."
I do not think that modifying input-file format is the best contribution you could make since the software exists for about 15 years and people will not be happy to throw away their old input files. Reading coordinates from another file is an option but you should be aware of the fact that OpenMX not only READS input files but also WRITES them (i.e. restart input file). It will take quite a while for you to go through the code and make the explicit coordinates section optional.
Otherwise I am also frustrated by the fact physicists inventing their own formats, input and output. OpenMX is far from being worst in this matter (VASP is the worst thing I encountered), however, I am really looking forward to people stopping this practice and sticking to existing file formats such as json (invented around 2000) and xml (1996). This is, of course, a matter of discussion in the scientific (physics, chemistry) community, however, if you go to IT guys and say that they have to learn your input file format to use your code they will probably laugh at you.
| Re: weird output in ".dat#" ( No.5 )|
- Date: 2017/03/26 18:20
- Name: T. Ozaki
- Dear Kylin,
If you want to transform the format of input files from another to that of OpenMX,
it would be easy to develop a pre-processing code. I wonder that there are a lot of
such small codes (e.g., VASP to QE and vice versa).
| Re: weird output in ".dat#" ( No.6 )|
- Date: 2017/03/26 23:53
- Name: Kylin
- Dear Artem Pulkin
I known the backward-capability is important. But I didn't intended to modify the format of input-file, just how openMX deal with the input-file. I hope it could do it more smartly. Even if we change the format of input file, we could also publish some convert tools to update older version of input file.
As for this post, the fault would be attributed to openMX. I didn't hope that after the simulation, the openMX tells us that the generated ".dat#" file was wrong. I think if the input-file contains any error (invisible tab "\t" in the current post), openMX should inform it in advance!!!.
Also, I think the invisible tab would not be problem for other simulation code, as least writen by C/C++. Thus openMX's Input part still exits some space for further improvement. Of course, that improvement would not change the calculation efficiency or results but just make people (at least me or other novice) more comfortable and convenient.
As for the format of input file, I known there is an organization openkim.org trying to unify them and want to allow the same model to be calculated by different code. But still not many people want to use it, everyone still did by their own style.