With newer versions of Petrel, the Project.ProjectVersion property will return a value that directly maps to the Petrel version. For example, a project saved with Petrel 2011.2 will have the Project.ProjectVersionvalue of "2011.2". However for projects created with older Petrel versions, the format is different. For example, a Petrel 2007 project might have the value 1024 and a Petrel 2005 project might be 824.
My question is, is there a published list anywhere that maps these numbers (1024 etc) to specific Petrel releases?
Here is the list of Project.Version possible values and versions of Petrel they translate to. Please note that in Petrel 2014.1 there will be a new Ocean API providing a Project's VersionInfo structure with a full version information, including string version, major, minor version numbers etc. Project.Version property will be obsolete in 2014.1.
0 project not saved yet, or project saved by Petrel version 2.0 or earlier
522 2.1
768 3.0
778 3.1
788 3.2
798 3.3
809 2002SE
818 2003
819 2003SE
828 2004
838 2005
848 early 2007.1 alpha
1024 2007.*
1034 2008.*
20091 2009.*
20101 2010.*
20111 2011.1
20112 2011.2.*
20121 2012.1
20122 2012.2
20123 2012.3
20124 2012.4
20125 2012.5
3329 2013.1
The list might not be complete and I will keep it updated.
I would leave this as a comment as it does not directly answer the question, but I don't have commenting privileges yet.
Have you tried the Schlumberger Software Support Portal?
Related
Our company used Pentaho Data Integration Community Edition (PDI-CE) 8.0 (Linux). We are upgrading to the PDI-CE 9.4. In the process, we met an issue.
To reproduce the issue, clone the project https://github.com/albertwangnz/reproduce-shared-objects-file-issue-pdice-9.4.
When we used PDI-CE 8.0, we used the feature Shared objects file in the transformation Miscellaneous tab. We defined database connections in different files to support different database engines. We set up a variable DB_CONN_SHARED_FILE in a previous transformation step. The value of the variable is the location of a shared object file (XML), like sharefiles/database-connections-mysql.xml. Then we used the variable as the value of the Shared objects file field as shown below. So, we could dynamically support various database engines, like MySQL, SQL Server, with the same *.ktr files.
It used to work in PDI-CE 8.0. But after we upgraded to PDI-CE 9.4, it does not work anymore. If we hard-code the value in the Shared objects file field, as shown below, like sharefiles/database-connections-mysql.xml, it works. But the variable does not work anymore.
I wonder if anyone met the same problem and knows how to fix it.
Thank you.
Regards,
Albert
The version of PDI-CE is 9.4.0.0-343
** The version of Linux is Ubuntu 18.04.6 LTS
We have two system one Running with JDK 1.6 and another with JDK 1.7. To communicate between the two node we are using ProtoStuff Serialization to convert binary & transfer to other node where its again the binary is de-serialized.
JDK 1.7 added new field 'suppressedExceptions', so now if we serialize the Throwable in JDK 1.7 in one node and transfer to another node its not able de-serialize & vice versa.
As two nodes uses different technology its not possible to migrate from JDK 1.6 to JDK 1.7 & JDK 1.7 to JDK 1.6.
Is there any solution to solve this problem, Thanks in advance for the reply.
With Regards,
Pavan
Protostuff-runtime does not support backward compatibility between two class versions if new field is added to one of base classes. This is caused by tag shift - when you add new field to base classe, all tag numbers in the childred classes are shifted. So, in general, there is no good solution for your problem.
But if you switch encoding to json, then problem should disappear. With protostuff-json, fields are stored using their names (instead of tags), so adding new field in the middle of class hierarchy should not be a problem anymore.
We are having a pdf which when opened in Acrobat Reader shows a version of 1.5 but when using Pdfbox(version 1.8.3) the version shows 1.3.
The code that we are using:
`aDocument.getDocument().getVersion()`
where aDocument is an instance of PDDocument.
Pdfbox version we are using is 1.8.3
Any help regarding this will be highly appreciated.
Hitesh Saliya already discussed that PDF in his question Adobe showing incorrect PDF Version (of PDF) in Properties. In this answer it became appearant that
version 1.3 was correct if one only takes the version header into account (there are no Version catalog entries in the document to consider);
at least version 1.5 was correct if one also took into account that object streams, cross reference streams, layers, and transparency are used.
In a way, therefore, both PDFBox and Adobe Reader are correct.
Thus, one first has to decide what one considers the version of a PDF document to be.
Is it the version the PDF file claims to be?
As a special case, what about PDFs claiming different versions? E.g. different entries in header and catalog, or different entries in different incremental updates.
Is it the version a chosen indicator program (e.g. Adobe Reader in a fixed version) recognizes for the PDF?
Is it the smallest / the largest version according to the respective PDF reference/specification the PDF is valid?
Could even any version in that range be a correct answer (resulting not in the version but the versions of a document)?
Some mixture of the above, e.g. the maximum of the version claimed and the lowest version according to which the PDF is valid?
Seriously, though, one can hardly expect anything more than option 1 to be implemented in a general purpose PDF library.
In Noda Time, we generate our documentation using Sandcastle and SHFB. We then commit the documentation back into the source repository - primarily because that makes it easy to view the latest (and historical) docs.
I'm the primary developer for the project, but I use two computers - and unfortunately, at the moment they're building different documentation even though they're both updated to the same source.
The two computers are the same in every important way I can think of:
Sandcastle 2.7.2.0
SHFB 1.9.6.0
VS 2012 Professional (both reported version 11.0.50727.1 in "Programs", both "Version 11.0.51106.01 Update 1" in the "About" page)
Latest version of local help content for .NET Framework 4.5 (and no local help content for other framework versions)
Steps taken to ensure a clean build:
Deleted the SHFB cache folder (C:\Users\Jon\AppData\Local\EWSoftware\Sandcastle Help File Builder\Cache)
Deleted the folder the documentation is generated into
Deleted the user settings file related to the SHFB project file
Deleted the symbol cache in Visual Studio
Still the differences remain. They appear to be limited to documentation inherited from MSDN itself, in particular Object.Finalize.
Version 1 (generated on machine "Chubby"):
<div class="summary">Allows an object to try to free resources and perform
other cleanup operations before it is reclaimed by garbage collection.</div>
Version 2 (generated on machine "Sandy"):
<div class="summary">Allows an <a
href="http://msdn2.microsoft.com/en-us/library/e5kfa45b" target="_blank">
Object</a> to attempt to free resources and perform other cleanup operations
before the <a href="http://msdn2.microsoft.com/en-us/library/e5kfa45b"
target="_blank">Object</a> is reclaimed by garbage collection.</div>
Both link to the same MSDN documentation, which looks like version 1 (no links to Object).
Looking at a few of the changed files, the change is consistent and restricted to this member.
Where might Sandcastle be getting this documentation from, and how can I get both computers to behave the same way?
EDIT: One more fragment of information - after cleaning the cache and rebuilding the docs on both machines, there are three files in the SHFB Cache directory:
Reflection.cache has the same size on both machines
MsdnUrl.cache has the same size on both machines
.NETFramework_4.0.0319_E8879A28.cache has size 13,377,733 bytes on Chubby, and 13,337,949 bytes on Sandy
EDIT: Significant progress! I've found where the difference is probably coming from...
The file c:\Windows\Microsoft.NET\Framework\v2.0.50727\en\mscorlib.xml:
On Chubby is 8,005,263 bytes with a date of 12th December 2011, and has the non-linked text for Finalize
On Sandy is 9,740,370 bytes with a date of 31st August 2009, and has the text for Finalize which includes links
On both machines, mscorlib.dll itself is the same size (4,550,656 bytes) and has a modified date of 13th September 2012.
But how can I get them to be the same? Where does that difference come from? (Service packs?)
EDIT: Okay, the version in c:\Windows was a red herring - it's the version in c:\Program Files (x86)\Reference Assemblies\Microsoft\Framework that's to blame. I'm going to see if I can find out why that might be different between installations...
A couple of ideas considering your recent edits, although I agree it is a bit shooting in the dark...
I would use a tool like "Beyond Compare" to compare the .Net Framework files and XML files on both machines ("folder compare" profile).
Favour the binary level comparison to be perfectly sure... if both of your machines are local, it should be very fast.
You can also try to run Mark Russinovich's Process Monitor ( http://live.sysinternals.com/procmon.exe ) on both machines and run the documentation building process.
This way, you will see which files are being read from and involved in the help file building process, and where they are coming from...
You will get a lot of output as it will show everything that happens in your system; you may want to disable registry and network monitoring, to only leave file monitoring, and also exclude any process unrelated to the documentation building process.
I'm not an help generation expert, but I would think that the text comes from the XML files, so you may want to put a filter on only showing the xml files as well.
If you can identify the files involved, then you might just have to copy them from one machine over to the other.
Expression Web 4.0 has the ability to export content and it's dependencies (a partial website). The format it exports in is a Microsoft Expression Web 4 Web Package (.fwp). Has anyone found a utility to convert this to a zip?
That's why I get for not actually investigating further. Turns out the first four bytes are 4D 53 43 46 (MSCF) which means that it's a CAB file with a different extension.
It contains all the files which have been renamed and flattened, as well as a manifest.xml.
Should be a short exercise with XSD.exe from here to make use of it.