glease / chemlib Goto Github PK

Well, after all, I still forget to add that.

• General xml marshall/unmarshall tests
• ChemDatabaseFinder tests
• IScope/IScoped tests

Moved from #3

• Cache the look up results if necessary. It should be noted that
  • cache records should be properly weighted to prevent memory monsters.
  • cache records should weight more if look up takes too much time.
  • cache records may be stored in SQLite file based database upon removal. This is yet only an idea, not a must.
• Add options to precompute tables to speed up look up. It should be noted that
  • the underlying finder may do nothing at all if the database is too small.
  • precomputation results should be soft referenced to prevent OOMEs.
  • the table containing precomputation results should be splited into parts to prevent being all removed in one gc.
  • add options to query for the percentage of surviving precomputation results.

• speed should be a function of temperature and pressure
• K should be a function of temperature
• temperature should be a range
• pressure should be a range
• reactant purity should be a range, and it's substitutable with concentration, measured in mol/l or similiar.

This project yet doesn't have a regular building mechanism. All classes are compiled with eclipse, which isn't that good.

Candidate:

• Maven/Ant
• Gradle

We may also let Travis handle building.

Moved from #3

• Cache the look up results if necessary. It should be noted that
  • cache records should be properly weighted to prevent memory monsters.
  • cache records should weight more if look up takes too much time.
  • cache records may be stored in SQLite file based database upon removal. This is yet only an idea, not a must.
• Add options to precompute tables to speed up look up. It should be noted that
  • the underlying finder may do nothing at all if the database is too small.
  • precomputation results should be soft referenced to prevent OOMEs.
  • the table containing precomputation results should be splited into parts to prevent being all removed in one gc.
  • add options to query for the percentage of surviving precomputation results.

All elements should have a scope. A scope maybe nested in another scope, i.e. has a parent scope. An element is identified with a property called id with type of String which distinct in the scope the element belongs to. An elements's ID uniqueness may not be tested in the parent scope and sibling scopes.

The javadoc generated by xjc is obscure. Need a thorough clean up.

This issue is of excessive low priority.

For some reason, we need it comparable. At least we should have a working comparator for those who are hard to think of a natural order

• Set all null, NaN or -1 to their defaults, if any
• Infer missing Atoms' localizedName and symbol from other Atom that has these values set. Throw NormalizationException if necessary.
• Add default Reactions' ids. (is this good? it seems to be tricky from the implementation perspective at the first glance)(removed because no Reaction could be added, or say binded to a ChemDatabase without an id.)
• Throw exception if there is an ID conflict.
• Throw exception if ID is reserved. e.g. a Reaction with ID atom111-244 may conflict with an Atom with index 111 and molMass 244.
• Throw exception if there is a logic error in the database, e.g. two Reaction with reversed reactant and resultant, identical conditions and catalysts, same temperature but has a different heat generation (except one is 0). Open for suggestions, while those not-so-worthy suggestions won't be implemented by the default implementation but provided for the sake of plugin developers.

Note:

• Don't check those conflicts that should be detected and immediately stopped by scoping mechanism.

Currently they won't be serialized.

Currently we have atoms, but no element. In general it will be OK, but it creates lots of issues. Mostly it's where the weird Normalizations come from. Should we isolate the concept into two parts: Element and Isotope?

How the new abstraction works

The Isotope generally replace the existing Atom, and Element is a higher level of abstraction. Atoms' states like index, localizedName, averageMolMass is pulled up to the Element, and the remaining part is named Isotope. An Element could have multiple Isotope, just as the real world elements have.

Pros

• No more inference needed about atom's localizedName etc.

Cons

• Modifying existing serialization and deserialization code may be troublesome. There are also other codes that needs modification, like normalization and xml files.
• SubstanceContent need to consists of one and only one of ELement and Isotope. This contract is hard to write.
• Some reactions may take Isotopes into consideration (like nuclear reactions, though they are not supported yet, I think we should make the types extensive enough so that we could implement it later). And that need a rewrite of some sort.

Question

Should we use this abstraction despite the difficulties of implementing?

• Add reagent purity
• Change equation's reactant and resultant not to use counted reagent. It should be counted substance. Solvent and concentration requirement should be included in this new complex type.

I'm ready for GA. Please see @1b8c7a35a6ead5261e2eb4bcfed663cbc48773ee

Currently some classes' hashCode is npt as good as it could be. For example, AtomImpl should use a larger prime to wipe hash collisions.

Because now we use hashmaps to speed up look ups, an id change will lead its components into harzard.

There are some hard limit on JAXB, I have to do it all manually.

Let there be some xml:

<equation>
<resultant reagent="s1" state="solid" />
......
<equation>

In fact s1 point to some substance, but in eclipse there is no error message at all. The key/keyref constraint should generate an exception here.

• speed should be a function of temperature and pressure
• K should be a function of temperature
• temperature should be a range
• pressure should be a range
• reactant purity should be a range, and it's substitutable with concentration, measured in mol/l or similiar.

There are some hard limit on JAXB, I have to do it all manually.

Left over of @0186f5d78e5aa9a46a822e08c60e329d932605fe. This is of excessive low priority.

Now serializing any Element will cause the serialization of the whole database, which is bad. We'd better drop serialization support until all issue (#18) is resolved.

Note: By

Drop serialization support

I mean that forward-compatibility is not guaranteed. Serialized data should only be used for short term usage like RMI, not for long term storage.

As stated in Apache License 2.0, I should:

OH MY F*CKING GOD WHAT SHOULD I DO!! THOSE LAWYERS DESERVE A PAINFUL -

Clamed down. HELP WANTED.

Add JAXB extensions, in <xsd:appinfo>.

Currently the only way to find certain equations, reagents and substances is to manually iterate the entire collections everytime, which may be an expensive action. It would also be boring to do it manually.

Goal:

• Provide means to find
  • equations with certain reactants, outputs, conditions and/or catalysts
  • substances with certain contents and/or a name.
  • reagents with certain substances, name, and/or state (maybe we should rename it to phase).