Actually, there are three issues here.
The first is that xsil2graphics hasn't been adapted to deal with binary
The second is that loadxsil.m (MATLAB specific, and the only currently
supported way to deal with the new binary file option) has undergone a
couple of recent bugfixes.
The third is that there should be a closing metalink tag - this has
been fixed in the development version.
There has also been a little bit of difficulty maintaining full
compatibility for some of the file handling routines. Paul and I are
on a stable "no known bugs on any platform" release, which should be
coming out soon.
A safe option would be to use the current version (2 or three less bugs
using ascii output. And watch the sourceforge site for 1.3-5.
On 14/07/2004, at 8:17 AM, Matthew Davis wrote:
> On Tue, 13 Jul 2004, Jim Cadien wrote:
>> Thanks for the help, however, it dosen't help me since I am
>> trying to use scilab. I just mentioned matlab, since I tried
>> that cmd as well, as a check on what was happening. Yes, the
>> docs do not say to do what you suggested. Is there something
>> like that required for scilab?
> OK, I've just had a quick go myself with scilab. It seems there is a
> problem with binary data and xsil2graphics. I would expect a closing
> </Metalink> tag in the xsil file, but there isn't one, maybe this is a
> bug? Putting it in by hand means that xsil2graphics runs without
> but the .dat file it creates is empty.
> As a workaround, if you change the output format to ascii rather than
> binary in nlse.xmds, rerun xmds and execute the whole
> simluation again, xsil2graphics will work without problem. Ie find the
> <output format="binary" precision="double">
> and change it to
> <output format="ascii" precision="double">
> Of course, this will use more disk space, but it will mean you can run
> it in the meantime! I'll ask Paul to have a look at the deeper problem
> when he arrives, I'm sure it won't take long to fix.