I couldn't use Jmol to open a 185 MB multiframe xyz file. I increased the memory available for java (via -Xms and -Xmx) to 1 GB, but this didn't help. The file opens in vmd without problems, using 5 % memory on a 1 GB system. That is about 50 MB, java allocates 64 MB on default (one can see that because jmol normally stops after using up 62 MB), so in theory, one should be able to do systems that are big enough without having to cross the default java memory barrier.
What is the issue here? I guess Jmol creates an object for every single coordinate in the xyz system. Otherwise one wouldn't be able to manipulate objects over all the frames instantaneously. The size of an object is probably larger than just the coordinates given in the input file, so memory size is blown up when going from xyz file to working memory. Cutting the file up seems the way to go. But would it be possible to have Jmol do that by itself? some sort of 'read multiframe' option where it detects multiframe files and reads them one frame at a time? Or are there too many disadvantages to that (not being able to edit objects in frames that aren't read yet, long loading times per frame). I guess also a problem is that one cannot always assume that the atom types and order stay constant over the multiframe file. Just some thoughts here, would be nice if Jmol could handle files like this without human interference or external shell scripts :) -- Greetings, Pim http://www.molmod.com ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Jmol-users mailing list Jmol-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jmol-users
