Separate Library construction not working.

[GoogleCodeExporter]

For which program(s) you want a new feature?
Simulator

Which build of the program(s)?
1.0-RC1

What operating system you use?
x86_64

What steps will reproduce the problem?
1. flux -t simulator -p f0.par -x
2. flux -t simulator -p f0.par -l

What is the expected output? What do you see instead?
When I run just:
flux -t simulator -p f0.par
the programs continues with the library preparation (crashes only at the end 
;-)). However if I do it in two separate commands, I get the following error:
[ERROR] Profiler has no molecules!

Original issue reported on code.google.com by peter.gl...@gmail.com on 5 Jul 2011 at 7:48

[GoogleCodeExporter]

Original comment by thasso.g...@gmail.com on 6 Jul 2011 at 10:31

• Changed state: Accepted
• Added labels: Simulator

[GoogleCodeExporter]

Can you please try with the new RC2. I was not able to reproduce the problem 
right now, but if it still exists, I will take a deeper look. 

Original comment by thasso.g...@gmail.com on 6 Jul 2011 at 6:08

• Changed state: Unconfirmed

[GoogleCodeExporter]

With RC2 the library construction runs by itself.

However, there are two errors during the process, second one being "fatal". See 
attached log.
I'm not sure what are any of those error statements trying to say.

Original comment by peter.gl...@gmail.com on 7 Jul 2011 at 3:04

Attachments:

• log

[GoogleCodeExporter]

Okey, one minor bug that I just fixed is that actually the first error was 
already fatal. 

What happens is that we try to read column 6 (field 5 in the error message 
because we start counting at 0) from the .pro profile file. For some reason you 
get an error that the column does not exist. Its the last column of a line (at 
least after the initial profile run) in the .pro file and contains the absolute 
number of molecules. for example:

chr1:11874-14409W       uc001aaa.3      NC      1652    4.3999683202280946E-5   
220

here, the 220 at the end is what we are looking for.

Can you attache your .pro file, I guess its f0.pro. If that is in fact invalid 
(which I am assuming), it would be great if you could also attach the .par 
parameters file and a compressed version of the .gtf annotation file. Otherwise 
I need you .pro to check for any strange characters. For that matter, are you 
on Windows or on a Unix box ?

Original comment by thasso.g...@gmail.com on 7 Jul 2011 at 4:42

[GoogleCodeExporter]

See attached archive.
You were right with the .pro file. The last line is not right. 

The system is CentOS 5, 64bit (I think it's Oracle HotSpot JRE). However, it's 
a new server so I tried it on the older one with Ubuntu Serer 64bit (OpenJDK), 
and it works OK. So I wasn't able to reproduce the error on the second machine.

But, in case that you are still interested ;-) I tried generating the .pro file 
a couple times (on the new server) and the last line gets corrupted, it seems 
like the the output wasn't "flushed" before the file was closed. Examples:

chr1:230838274-230850336C       uc009xfe.2      CDS     1929    
2.2080220802208022E-4   1104
chr1:230838274-230850336C       uc009xff.2      CDS     2495    1.6<no end of 
line>

chr1:226548393-226595801C       uc001hqd.3      CDS     3984    
7.87996848012608E-5     394
chr1:226723319-226730469C       <ends here>

chr1:235824345-236046940C       uc001hxi.2      CDS     8291    
5.9600238400953606E-5   298
chr1:235824345-236046940C       uc001hxj.2      CDS     13476   1.056004224

Original comment by peter.gl...@gmail.com on 7 Jul 2011 at 5:29

Attachments:

• testFiles.tgz

[GoogleCodeExporter]

Sorry, forgot to mention, it's not just the last line (which can be judged from 
different "last" transcripts) the number of lines changes as well.

So it obviously just doesn't finish writing.

Original comment by peter.gl...@gmail.com on 7 Jul 2011 at 5:33

[GoogleCodeExporter]

Thanks for the info. I will check for any missing close() or flush() 
statements. 

Just out of curiosity, can you check which Java version is used on your CentOS 
machine ( the one where the error occurs ). Maybe I could install the same 
version here and reproduce the bug.

Original comment by thasso.g...@gmail.com on 7 Jul 2011 at 5:46

• Changed state: Accepted

[GoogleCodeExporter]

The java version is:
$ java -version
java version "1.6.0_26"
Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode)

We have multiple installations, so I also tried:
java version "1.6.0_20"
OpenJDK Runtime Environment (IcedTea6 1.9.8) (rhel-1.22.1.9.8.el5_6-x86_64)
OpenJDK 64-Bit Server VM (build 19.0-b09, mixed mode)

And the problem persists.

Original comment by peter.gl...@gmail.com on 7 Jul 2011 at 6:06

[GoogleCodeExporter]

Hi,

as Thasso already suggested 
(http://code.google.com/p/fluxcapacitor/issues/detail?id=52#c1), for enhancing 
compliance with the Flux library, or Java code in general, I would recommend to 
prefer the Oracle (Sun) JDK over the OpenJDK. We had already heavy issues due 
to different thread handling, and if I read that report right, it seems that 
file I/O also differs. See also the opinion posted there: 
http://stackoverflow.com/questions/4422808/oracle-sun-jdk-vs-openjdk

My 5 cents,

micha

Original comment by gmicha@gmail.com on 7 Jul 2011 at 6:48

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I'm experiencing the same problem here with FluxSimulator-1.0-RC2 on CentOS 5.6 
and this java version:
java version "1.6.0_24"
Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
Java HotSpot(TM) Server VM (build 19.1-b02, mixed mode)

I'm running the demo dataset without modifying anything. Same exception as 
Peter (however the index causing the ArrayIndexOutOfBoundsException can 
change). As for Peter, the output of the .pro file is not flushed (it has a 
"perfect" size of 409600 bytes!).

Original comment by mikael.s...@gmail.com on 12 Jul 2011 at 7:24

[GoogleCodeExporter]

I found the flush problem and its fixed. The fix will be incorporated in the 
next release (RC3).

Original comment by thasso.g...@gmail.com on 12 Jul 2011 at 11:23

• Changed state: Fixed